Prefer getters over fluent setters for input field types

[oryan-block]

Fixes #446

Checklist

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

Description

A schema with input RepairApplyInput { repairMan: RepairManInput } and a mutation that takes RepairManInput directly fails to build with Two different classes used for type RepairManInput, where one of the two classes is RepairApply itself. The only workaround in the thread is duplicating the input type under another name. The reporter didn't post their entity classes, but you get the exact same error when the entity has a fluent setter, like the public RepairApply repairMan(RepairMan repairMan) { ...; return this; } JHipster generates, or the repairMan() + repairMan(RepairMan) pair from Lombok's @Accessors(fluent = true). Without the fluent setter the same schema builds fine on master.

SchemaClassScanner#findInputValueTypeInType finds the Java type of an input field by taking the public methods named x or getX, sorting them by name length and using the return type of the first non-synthetic one. It never looked at parameters. repairMan(RepairMan) has a shorter name than getRepairMan(), so it wins and RepairManInput gets mapped to its return type, RepairApply. That clashes with the RepairMan parameter of createRepairMan.

Now getters without parameters come first (non-synthetic first, same as before), then the public field, and only then methods with parameters, picked the same way as before. My first version dropped methods with parameters completely, but that broke schemas that build on master. For example a class used for both type Foo { bar: Bar } and input FooInput { bar: BarInput } with getBar(DataFetchingEnvironment), setBar(Bar) and a private field. If BarInput is only reachable through FooInput.bar, it never got discovered and makeExecutableSchema() threw Expected type 'BarInput' to be a GraphQLInputType, but it wasn't!. Same for an input class that only has a fluent setter. Keeping them as the last resort means those resolve exactly as on master. scanner finds input field types through getters with arguments covers that case. scanner ignores fluent setters when finding input field types covers the issue with a JHipster-style property, a Lombok-style pair and a @JvmField field, each with a fluent setter, and fails on master with the same error as the issue.

I didn't try to use a fluent setter's parameter type when there's no getter or public field. Telling a fluent setter apart from a getter with arguments would need a heuristic (one parameter, returns the declaring type) that gets things like Foo getParent(env) on Foo or Map.remove(Object) wrong. So a class with only a fluent setter x(X), or with x(X) and getX(env) but no getter without parameters, still resolves to the setter's return type, same as on master. Neither is needed for #446.

Behaviour change: when an input class has a getter without parameters (or a public field) and a method with parameters for the same field, the field's Java type now comes from the getter or field. So schemas that failed with "Two different classes used for type X" because of a fluent setter now build. Classes that only have methods with parameters for a field resolve as before.

🤖 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