Adopt Class File API (preview feature Java 22)

[rfscholte]

See https://bugs.openjdk.org/browse/JDK-8308754 , which means that as of that version this should be the preferred way to parse class files over ASM, i.e. introduce a src/main/java22 with the required code.

[jorsol]

The issue is that preview features require running with --enable-preview, so it should not be the preferred way until it's GA.

The bad news is that if you introduce src/main/java22, the classes will need to be compiled with --enable-preview (which is perfectly possible), but then every single run on Java 22 would require using --enable-preview at runtime and that might not be desirable (or might not be even possible on some scenarios), also using MRJAR, would mean that Java 23+ will break when you compile code that targets Java 22 (with --enable-preview) code with 22's compiler and try to run it with 23 you get an UnsupportedClassVersionError (preview features are not intended to be in production code).

Yet, there is some good news to actually start adopting the Class File API before its GA, but it requires introducing a dependency: https://github.com/Glavo/classfile, with this dependency is possible to use the Class File API even in Java 17, so one idea should be to actually introduce the dependency in src/main/java17 to use and test the Class File API (using org.glavo.classfile), and when the Class File API is finished introduce something like src/main/java25 and it will be just a swap of org.glavo.classfile to the new java.lang.classfile.

[rfscholte]

I agree that it should not be added as long as it's a preview feature, for the reasons you mention. Currently upgrading ASM is sufficient to support the latest Java version to read the module descriptor, so there's no real rush to implement this.

[jorsol]

Proposed to be targeted in Java 24: JEP 484: Class-File API, once this is integrated it can be added to plexus-languages.

[anthonyvdotbe]

@slachiewicz will you please reopen? I'm unable to compile tests with JDK 28, because of the dependency on AsmModuleInfoParser.

Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 72
    at org.objectweb.asm.ClassReader.<init> (ClassReader.java:200)
    at org.objectweb.asm.ClassReader.<init> (ClassReader.java:180)
    at org.objectweb.asm.ClassReader.<init> (ClassReader.java:166)
    at org.objectweb.asm.ClassReader.<init> (ClassReader.java:288)
    at org.codehaus.plexus.languages.java.jpms.AsmModuleInfoParser.parse (AsmModuleInfoParser.java:48)
    at org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor (AbstractBinaryModuleInfoParser.java:43)
    at org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor (AbstractBinaryModuleInfoParser.java:35)
    at org.codehaus.plexus.languages.java.jpms.LocationManager.getMainModuleDescriptor (LocationManager.java:304)
    at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths (LocationManager.java:143)
    at org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths (TestCompilerMojo.java:267)

[slachiewicz]

Reopened. Do you have plan to work on fix for this?

[anthonyvdotbe]

Not at the moment.

[slachiewicz]

What is your proposed way to fix it?
This library needs to keep java 8 compatibility

[jorsol]

By leveraging Multi-Release JARs (MRJARs / JEP 238), the library can run seamlessly on Java 8 using a legacy fallback (e.g., ASM or reflection) while automatically utilizing the native Class File API when running on Java 24+.

The plexus-java already uses multi-release JAR, the idea is to have the following:

• Abstraction Layer (Java 8 Base): Define a unified internal interface for bytecode operations.
• Legacy Provider (Java 8 Base): Provide a Java 8-compatible default implementation (e.g., powered by ASM).
• Modern Provider (Java 24 Version): Provide a Java 24 implementation using java.lang.classfile.*.