Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

hex539
Copy link

@hex539 hex539 commented Jul 9, 2025

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.

@hex539 hex539 changed the title Adapt NodeList.getFirst/getLast to Java 21 Fix compile and test errors for Java 21 and up Jul 9, 2025
@jlerbsc
Copy link
Collaborator

jlerbsc commented Jul 9, 2025

Thank you for your suggestion, but it's a problem because it would force all JP users to use Java 21.

@hex539
Copy link
Author

hex539 commented Jul 9, 2025

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().
@hex539
Copy link
Author

hex539 commented Jul 9, 2025

Updated the PR to use shadowing for now.

@jlerbsc
Copy link
Collaborator

jlerbsc commented Jul 9, 2025

It's also a change that breaks the interface and impacts all JP users. This is not desirable.

@hex539
Copy link
Author

hex539 commented Jul 9, 2025

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
@jlerbsc
Copy link
Collaborator

jlerbsc commented Jul 18, 2025

As I said, this type of modification will not be included in the project because it would involve breaking the API too much.

@hex539
Copy link
Author

hex539 commented Jul 21, 2025

For completeness: the one other modification that would be possible to make the project compile on modern versions of Java while leaving the custom getFirst() and getLast() in place would be to remove implements List<N> from NodeList and reimplement the missing functions inline or with a delegate. This works as long as no user is trying to cast NodeList to a List.

I would also be happy to try that, with two reservations:

  • it feels like a worse change that also would not be accepted, because even though it keeps API compatibility for the most part, it requires a lot of boilerplate to reimplement all of List.
  • my impression of the above comments is that the project simpl has a policy of not compiling in Java 21 or above and it will never support compilation on any version of Java released after 2023.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cant build
2 participants