-
Notifications
You must be signed in to change notification settings - Fork 5
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
read of JPMS multi-release jars fails if a newer version than supported is present #32
Comments
I can confirm that the code now looks for the first |
Fixed with 020a7f2 |
Hi Robert, I'm experiencing this issue – is there a way to benefit from this fix already? I added
to
|
This is curious, the move of the enum to a top-level element happened in 2018: 01d3f9f#diff-832e0b5d7b97ff4be7e6e22b2751e50fe5670dfe219e438617bb6dc194d9280c So there seems to be some other dependency that hasn't been updated. Perhaps it was also broken before, but no referring class was initialized on the MR-less codepath, so it never showed up as an exception. I explicitly specified the versions of
to no avail. |
Maven Compiler Plugin 3.8.1 is using plexus-java-0.9.10, see http://maven.apache.org/plugins/maven-compiler-plugin/dependencies.html |
@rfscholte Thanks!
Yes, I hoped that I would be able to upgrade the plexus-java dependency on its own, but as I figured out they weren't binary compatible.
Is there any idea when the next maven-compiler-plugin release is planned to ship? |
I think everybody will look at me to do the release, but any Maven committer can do it. I first have other topics to work on, but we should do one before Java 17. I'd suggest to ask for a release in September. |
Thanks for the info! |
JEP 238 multi-release jars are intended to support new JDK releases in a backwards compatible way.
However, if you create a trivial JPMS project with a dependency on a multi-release jar that contains a newer version than the JDK used to run maven, you risk getting a fatal exception from the maven compiler plugin that blocks compilation:
This is because
AbstractBinaryModuleInfoParser::getModuleDescriptor
iterates through all module-info.class files found in a jar in an unordered way, and simply takes the first one found.For example, a trivial project with dependency:
compiled on the platform below gives that error
This is because
tech/units/indriya/2.0.4
(as available on maven central) has:And so in JDK 11, it tries to read the JDK 12 version first, which throws the above exception.
Refs:
https://openjdk.java.net/jeps/238
The text was updated successfully, but these errors were encountered: