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.

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 a2018 copy of the project. This version does compile with JDK 24 as7d86f54 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.

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 customgetFirst() andgetLast() in place would be to removeimplements List<N> fromNodeList and reimplement the missing functions inline or with a delegate. This works as long as no user is trying to castNodeList to aList.

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 ofList.
• 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.