Multi-Release JARs (MRJARs) pick the wrong class on higher Java versions

[JoseLion]

Libraries in the classpath with a Multi-Release structure work fine when using the lowest allowed Java version. However, when using a higher version that provides a replacement class, VSCode loads the lower version instead of the replacement. Another interesting thing is that when looking at the library on the Java Project Explorer using a higher Java version, classes with a replacement show duplicates, but they all switch back to the lowest when opened.

Environment

• Operating System: Windows 11 - 22H2 (build 22621.2283)
• JDK version: v20.0.2 (Gradle Java Toolchain for 11 and 17)
• Visual Studio Code version: v1.82.2
• Java extension version: v1.22.1

Steps To Reproduce

1. Add a Multi-Release JAR dependency to a project.
   • For these steps, I'm using Maybe for Java, which is a library of my authoring. This way, I know the Either interface has a replacement for Java 17, which makes the interface sealed, plus it uses record classes for the implementations.
   • This means that on Java 11, you could make any class implement Either. But on Java 17, trying to implement Either should show a compilation error.
2. Make sure to use the lowest allowed Java version for the library (e.g., Java 11)
3. Use the Java Project Explorer to ensure the MRJAR lib has the META-INF/versions folder with replacement classes
4. Import a class with replacement (e.g., import io.github.joselion.maybe.utils.Either;)
5. Go to the definition of the imported class. It should show its lowest version (e.g., interface without sealed keyword and no records)
6. Switch to a higher Java version (e.g., Java 17)
   • Using Gradle and the Java Toolchain can be useful
   • You may need to run the Java: Clean Java Language Server command
7. Use the Java Project Explorer to verify the META-INF directory does not contain versions anymore
8. Go to the definition of the imported class again. It still shows the lowest version (e.g., it should show a sealed interface and records instead)

Sample project: java-sandbox.zip

Logs: Nothing is logged during the process

Current Result

MRJAR references the lowest version class when using a higher Java version

Expected Result

MRJAR references should use the matching class based on the current Java version.

Additional Information

I'm willing to help with a PR if someone can point me in the right direction. Knowing where and how this should be handled will be of great help 🙂

I'm also adding some screenshots of the Java Project Explorer with an MRJAR dependency expanded.

With Java 11:

With Java 17:

[maxandersen]

I have the same issue when using https://hub4j.github.io/github-api/ there is two versions of HttpClientGitHubConnector and it keeps picking the <11 version rather than >11 even when version set to 17.

[rgrunber]

Might https://github.com/eclipse-jdt/eclipse.jdt.core/pull/3900 help support this better ?

[laeubi]

@rgrunber I don't think this will address the mentioned issue here, but of course it would be good if JDT could better support MR-Jars in the IDE and we then improve the overall support.

In general I think initial report is invalid, the MR Specification contract that says that all (public) API needs to be the same for all releases, having an interface being sealed likely violates this. Of course JDT should still pick the lowest matching of the project settings.