search

unitsofmeasurement / indriya

JSR 385 - Reference Implementation
Other
118 stars 40 forks source link

can't use from jpms, maven 3.6.3, openjdk 11 #301

Closed richard-melvin closed 4 years ago

richard-melvin commented 4 years ago

My project, which uses jpms, has a dependency on indriya 2.0.4:

Compilation on JDK11 fails with what appears to be a maven bug:

https://github.com/codehaus-plexus/plexus-languages/issues/32

Reporting not so much in the hope of fix at your end as in case it helps someone else with the same problem.

keilw commented 4 years ago

There seems to be more than one problem with multi-release-jars, we also discovered this in https://github.com/unitsofmeasurement/uom-demos/tree/master/console/java12. The Java 12 declaration does not work unless you use at least Java 13. And more severely if you use JPMS by declaring a module-info, the multi-release code isn't recognized at all, I think you may have stumbled over a similar issue with Java 11. I have not tried but possibly an automatic-module-name declared in the MANIFEST might work. Would that be sufficient in your case? Using JDK 13 or 14 but building it with Java 11 compatibility in your Maven POM should work.

I also don't see how we cold fix that ourselves, it may require Java 15, 16 or even further to be fully addressed in the JDK I'm afraid.

richard-melvin commented 4 years ago

Thinking about it, it's possible you could hack in a workaround by building the multirelease jar such that the java 9 directory comes first, not last, as it does in an alpha sort.

I guess the reason it works on openjdk 14 is that they removed the explicit check and exception when reading module-info.class. maven will still be loading the 'wrong' version though, which would presumably cause subtler issues, if there was a meaningful difference between them

keilw commented 4 years ago

I doubt it, because META-INF/versions/9/ is predefined, so what would that change at runtime? And I don't see why it's a maven problem, the JVM or module-path resolution seems to fail.

I'm not sure, if this was the only one, but this JDK bug https://bugs.openjdk.java.net/browse/JDK-8207162 was what I came across during the POC with the visibility problem. Apparently not everything was fully fixed in Java 12 as the issue states because at least https://github.com/unitsofmeasurement/uom-demos/tree/master/console/java12 only starts to work from Java 13 onward. I may try it again with "jdk-12.0.2.10-hotspot" if 12.0.2.10 really had anything fixed under Java 12, otherwise it still fails in any 12 update. In 11 or before it wasn't fixed at all.

keilw commented 4 years ago

I was able to reproduce the problem building https://github.com/unitsofmeasurement/uom-demos/tree/master/console/java10 or https://github.com/unitsofmeasurement/uom-demos/tree/master/console/systems/common-java10. Running it with Java 12 (jdk-12.0.2.10-hotspot) or above works, therefore the bug lies in Java 11 and has not been fixed despite its LTS label. Will close this, please use Java 12 or higher, or Indriya 2.0.2 which did not use Multi-release-JAR yet.

keilw commented 3 years ago

@richard-melvin Turns out, this was mainly caused by a JDK bug first discovered in Java 11, but not fixed until 16. So from Java 16 on the module-info should be properly resolved and no accidential fallback happen, but to support earlier Java versions, we'll keep them both.