-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle getters of java.util.Record. Upgrade gson to safe version. #425
Handle getters of java.util.Record. Upgrade gson to safe version. #425
Conversation
SPQR is still on java 8 (as graphql-java is on Java 8). In the next release, they're upgrading to Java 11, and SPQR will follow. |
This PR will not require a move from Java 8. It will however allow users of these libraries to use higher versions of Java. I've been using this patch with Java 17. I don't see a reason for a new module as this change is fully backwards compatible and requires no changes to the build configuration. |
Oh, I see... You don't actually check if the class is a record. That would cause backwards incompatible changes to people's schemas (new fields suddenly exposed without changes in the configuration). So ideally, this would be turned into its own |
I'll take a look and let you know. Thank you for considering the change. |
Thank you for contributing! |
@kaqqao I started working on this but am having trouble replicating the issue of a method suddenly appearing in the schema. Could you recommend a Unit test? I created two ResolverBuilders and reverted changes to ClassUtils but want to ensure I haven't missed anything:
|
I've just added 2 new
See #453 for more details. I'm really sorry for not merging your PR, but I think dedicated builders are the way to go here, as that ensures full backwards compatibility. |
No description provided.