-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Fix compile and test errors for Java 21 and up #4794
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
base: master
Are you sure you want to change the base?
Conversation
Thank you for your suggestion, but it's a problem because it would force all JP users to use Java 21. |
Good point. Would shadowing the methods work for you? If not, the option I had originally considered was just renaming the methods to something like getOptionalFirst and getOptionalLast so that they don't clash with Java 21 any more. |
Java 21 reserves List<T> methods getFirst() and getLast() to return objects with type T. The original methods added to return an Optional<T> are removed in favour of using the default implementation. Existing callsites are easy to convert: either check size() first if the callsite was using ifPresent(), or directly get the object in case the code was already calling getFirst().get() or getLast().get().
Updated the PR to use shadowing for now. |
It's also a change that breaks the interface and impacts all JP users. This is not desirable. |
It's unfortunate that JDK created different canonical signatures for getFirst/getLast from the ones added here (this issue affected many other projects that created custom getFirst/getLast too). However, JDK will never remove these methods from List interface. So if the getFirst/getLast here aren't changed, it will become impossible to compile javaparser on any future released JDK ever. For now it's reasonably convenient for developers to pin an older JDK but this will become harder over time. For background, I'm looking to update this downstream fork for Android, which currently has a 2018 copy of the project. This version does compile with JDK 24 as 7d86f54 wasn't included in the codebase back then: If the project's PoV is that nobody should be using JDK newer than 20, I can try and port the change into the downstream project and leave it out of upstream. However it seems like a change that has to be made at some point eventually anyway, so I thought I'd try it here. |
By updating the list of known JDK versions with that range. Also adds the javaVersion string to the test error message for ease of diagnosis. Change-Id: Ib808a32fc93ce895847be01d1dc9961746c8b291
As I said, this type of modification will not be included in the project because it would involve breaking the API too much. |
For completeness: the one other modification that would be possible to make the project compile on modern versions of Java while leaving the custom I would also be happy to try that, with two reservations:
If those observations are correct, what I can try to do instead is update the copy of Javaparser in that project and apply the Java 24 compilation patches on top. From my testing this seems to work well and various tools built with Java 24 can use the newest version of the library. |
Java 21 reserves List methods getFirst() and getLast() to return objects with type T. The original methods added to return an Optional are removed in favour of using the default implementation. The tests for these methods go away as well because they would be redundant now.
Existing callsites are easy to convert: either check size() first if the callsite was using ifPresent(), or directly get the object in case the code was already calling getFirst().get() or getLast().get().
Fixes #4454.