getting java.lang.NoSuchMethodError: graphql.schema.GraphQLType.getName()Ljava/lang/String;

[ravibegari]

Detailed message: Error: Error loading a referenced type: java.lang.NoSuchMethodError: graphql.schema.GraphQLType.getName()Ljava/lang/String; Trace: at parsing io.leangen.graphql.generator.TypeCache.(TypeCache.java:19) Call path from entry point to io.leangen.graphql.generator.TypeCache.(Collection): at io.leangen.graphql.generator.TypeCache.(TypeCache.java:18) at io.leangen.graphql.generator.BuildContext.(BuildContext.java:106) at io.leangen.graphql.GraphQLSchemaGenerator.generate(GraphQLSchemaGenerator.java:992)

Dependencies are implementation 'com.graphql-java:graphql-java:17.3' implementation 'io.leangen.graphql:spqr:0.10.1'

[ravibegari]

HI Team, I am getting the above error, it will be great if you can help me

[ravibegari]

is there any way to use graphqlSchemaGenerator+DataFetchers in AWS serverless applications ?

[sgrannan]

@ravibegari I had to downgrade from graphql-java 17.3 to 16.2 when I was getting a similar mysterious error NoClassDefFound. What other libraries are you using or did you pull in graphql-java library on its own?

[kaqqao]

NoSuchMethodError can only mean one thing: you're running against an incompatible version of graphql-java. SPQR can only run against the graphql-java version it declares as a dependency. If you override underlying library versions, you're asking for trouble. Dependency management exists for a reason.

[sgrannan]

I feel like the mysterious and ambiguous errors like NoClassDefFound or NoSuchMethodError shouldn't be the expected behavior whenever there is a version mismatch. When creating libraries we always try to be as succinct as possible with our exception handling. Is there not a better way of handling the exception when things start to autowire up?

You definitely could benefit by informing the user better that they are using a incompatible library. For what its worth, we decided not to use GraphQL SPQR anyway for lack of support/adoption of this particular library back in 2022.

[kaqqao]

mysterious and ambiguous errors like NoClassDefFound or NoSuchMethodError shouldn't be the expected behavior whenever there is a version mismatch

What can a class do if you replace the bytecode it depends on under its feet? Any class that is compiled and run with different versions of its dependencies will result in this exact same error. It's not ambiguous at all. This is why we have dependency managers in the first place. You have to know what you're doing in your own build if you decide to override major versions, with documented breaking changes.

You definitely could benefit by informing the user better that they are using a incompatible library.

Dependency information is communicated in the same way in all Maven based projects - by declaration in pom.xml.

we decided not to use GraphQL SPQR anyway for lack of support

This is an open source project that you get for free. If you find it lacks support, you're welcome to contribute.