Support generic input types

A GraphQLResolver<Base> is now used for any data class extending or
implementing Base. Resolvers are searched most specific first, followed
by the data class itself.

Fixes #497

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…rfaces and unions

Handling all unused types at once required a dictionary class for types
that would have been discovered by scanning another unused type. Unused
interfaces and unions are now included without a class, and unused enums
missing from the dictionary are only reported as unused instead of failing.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Add support for unused types for all dictionary types

- Cover case where a GraphQLResolver<Base> method and a getter on the subclass both match a field
- Move scanQueueItemForPotentialMatches next to related scan methods (no behavior change)

Support resolvers for supertypes of data classes

Build the built-in directive map from the individual Directives constants
instead of Directives.BUILT_IN_DIRECTIVES_MAP, which only exists in
graphql-java 26, so the same jar works with both 25 and 26.

Also clarify where the default @deprecated reason comes from and add a
TODO to narrow SchemaObjects.dictionary in the next major version.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Support graphql-java 26

Cover nested generic object types (#415, #314), generic input classes with
several parameterizations or nested in other inputs (#333), enum list
argument defaults (#444), input field defaults (#298) and anonymous Java
class resolvers (#714). Also make SchemaParserBuilderTest fail when no
syntax error is thrown.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Directives on `schema @foo { ... }` and `extend schema @foo` were never
read, so e.g. Apollo Federation v2's `extend schema @link(...)` was
missing from the GraphQLSchema and from federation-jvm's _service.sdl.
They're now added as schema applied directives, the schema definition's
first, then its extensions'.

RootTypeInfo also took the last SchemaDefinition, which can be an
extension, so `schema { query: MyQuery }` followed by `extend schema @foo`
lost the custom root type. Operation types are now merged across the
definition and its extensions.

Only applied directives are set on the schema: graphql-java doesn't
resolve type references in the deprecated legacy schema directives, so
an enum argument would fail validation.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

The Publisher return type check for subscriptions was applied whenever
the resolver instance implemented GraphQLSubscriptionResolver, so a
class that is also a query or mutation resolver lost all of its
non-Publisher methods and failed with "No method found". The check and
the missing method note now depend on the root type being scanned,
which RootResolverInfo records.

The checks were also inverted: they accepted supertypes of Publisher
and CompletableFuture rather than subtypes, so Publisher
implementations such as Flux were rejected. Accept Publisher subtypes,
futures of them (Future or CompletionStage, with class, parameterized
or wildcard type arguments) and ReceiveChannel subtypes that have a
wrapper registered for that exact type. Methods erased to Object, such
as suspend functions, are still accepted since their return type can't
be checked here.

Generic wrappers only unwrap their exact type, so subscription return
types are now matched against the schema as a Publisher of their
events. Otherwise a Flux<Item> return, or a covariant override of a
Publisher<Item> method, would map the Item type to the Flux class.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Type variables in field and method types were resolved against the
declaring type, which only knows the arguments passed in by its direct
subclass. When those were type variables too (e.g. Item extends
BaseItem<Long> extends AbstractItem<T>), the fallback matched them by
name against the first parameterized superclass. That recursed forever
when the names repeated, failed with "No type variable found" when they
differed, and silently picked the wrong argument when a subclass
reordered them.

Resolve them against the most specific type instead, which binds the
type variables of all its supertypes, or its owner types for those of
outer classes, and drop the name matching. Variables in wildcard bounds
(e.g. List<? extends T>, which Kotlin emits for List<T> parameters) are
resolved too. A variable that can't be resolved, such as one declared
by a generic method, fails with a clear error. One bound to a type
containing itself, which can only leak out of a raw type, is erased
like the raw type would instead of being expanded endlessly.

Generic types returned by methods of a generic superclass now keep
their resolved arguments, as fields already did. So two subclasses
binding them differently can't share one GraphQL type anymore, like
direct references to Page<A> and Page<B>. The "Two different classes"
error now prints the parameterized types to show the difference.

Fixes #460
Fixes #218

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Fix subscription resolver return type validation

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

- New SchemaParserOptions.allowUndeclaredDirectives, off by default
- Undeclared directives are kept as applied directives only, with argument types guessed from their values
- Fails with a SchemaError when an argument type can't be guessed

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Support directives on the schema

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…gh unions

…lder chain

…resolves

Query every field of every test schema

Resolve type variables in resolver parameter types

…-types

Resolve type variables in resolver return types

Logs a warning for a directive applied at a location its definition doesn't
list, without a required argument, or more than once when it isn't repeatable.
The schema still builds as before. Arguments of directive definitions now get
the ARGUMENT_DEFINITION location instead of OBJECT.

Fixes #225

The scanner only expanded a nested union that some field returned, so a union listed only as a member of another union failed with "No object type found". It now discovers those unions too, so they build the same way as when a field returns them.

…nd-environment

Allow resolver methods to take both the context and the environment

withDirectives is deprecated, so writing the location twice goes away with it.

…ment

Every Directive node carries its source location, so the warnings don't need a name threaded through
createField and createArgument.

…ate-directives

Warn about directives applied where their definition doesn't allow them

Build unions that are only members of other unions

…argument-on-context

Warn at build when a resolver method is missing a parameter for an argument

The data fetchers looked each argument's type up in the request's schema. The scanner already knows the scalar names, so each argument is checked once when its data fetcher is created.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…rough

A [[String]] argument for a List<Set<String>> parameter was passed through as a list of lists, because every list level checked the outer parameter type. Each level now checks its element type, so the inner lists are converted to sets.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…r-args-at-build

Check scalar arguments when building the schema

…d dictionary entry

…he same class

…zed-dictionary-type

Resolve union and interface values by the raw class of a parameterized type