Apply raw and star-projected resolvers to parameterized data classes

[oryan-block]

Fixes #308

Checklist

• Pull requests follows the contribution guide
• New or modified functionality is covered by tests

Description

A resolver for a generic data class is never linked to fields that return a parameterization of it. In #308, TestResolver implements GraphQLResolver<TestDataClass> is ignored for a query returning TestDataClass<MyType>. So with GraphQLResolver<Page> and a field returning Page<Item>, the build fails with FieldResolverError: No method or field found as defined in schema ... for the fields the resolver provides. If the data class has its own getter, the resolver just sits there with the "Resolver was provided but no methods on it were used" warning. Kotlin can't express raw types at all, and GraphQLResolver<Page<*>> fails even earlier with ResolverError: Unable to determine data class for resolver ... This is most likely a bug with graphql-java-tools.

SchemaClassScanner.getResolverInfoFromDataClass matched resolvers with it.dataClassType == dataClass. For a field returning Page<Item>, dataClass is a ParameterizedType, which never equals the resolver's Class. isResolverForSupertype also required dataClass is Class<*>, so resolvers for a supertype or interface were skipped too. On top of that, NormalResolverInfo.findDataClass only accepted a Class as the GraphQLResolver type argument, and Kotlin's Page<*> compiles to Page<?>.

Resolvers, including supertype and interface ones, are now matched against the raw class of the data class type. MultiResolverInfo keeps the parameterized type for the data class search, so fields typed by a type variable (content: List<T>) still resolve. With the raw class they fail with "Could not resolve type variable ... declaring type is not parameterized". A new eraseUnboundedWildcards() helper turns a type whose type arguments are all unbounded wildcards into its raw type. findDataClass uses it, so GraphQLResolver<Page<*>> and GraphQLResolver<Page<?>> behave like GraphQLResolver<Page>. verifyMethodArguments uses it for the source parameter, so getSize(page: Page<*>) is accepted. Kotlin emits an unbounded Page<?> for Page<*> even when T has an upper bound, so star projection always works. The raw resolver test is in ResolverMethodsTest.java since Kotlin can't express raw types.

I didn't add resolvers for one specific parameterization (GraphQLResolver<Page<Item>>, or bounded wildcards like Page<out Foo>). Picking a resolver per type argument needs a design decision. Those now fail with "Resolver 'X' may not have a parameterized type (Page) as its type, use the raw type or unbounded wildcards (<?> in Java, <*> in Kotlin) instead." instead of pointing at a library bug. Bounded wildcards aren't treated as raw, since that would apply a Page<? extends Foo> resolver to Page<Bar>. For the same reason, a source parameter typed Page<Item> on a Page<*> resolver still isn't matched, and the build fails with FieldResolverError like on master. Accepting it would call the method for Page<User> too and throw a ClassCastException at query time. GenericType isn't touched, so this doesn't overlap with #825.

Behaviour change: a resolver for a raw generic class, for Foo<*>/Foo<?>, or for any of its supertypes or interfaces now applies to fields returning a parameterization of that class. Before, it was ignored. So if both the resolver and the data class define the same field, the resolver method now wins, like it does for non-generic data classes. Supertype resolvers already applied to non-generic subclasses since #820, and now they apply to parameterized ones too. If such a resolver method replaces a data class getter, the class found for a field's type can change, and a schema that used to build can fail with "Two different classes used for type X". For example, BaseResolver : GraphQLResolver<Base> with children(b: Base): List<Child>, a Holder<T> : Base with children: List<T>, and a query returning both Holder<SpecialChild> and SpecialChild. That builds on 14.1.0 and fails with this change.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud