'requires transitive java.annotation' leads to runtime exception
FrankHuxol opened this issue · 9 comments
When launching our application we get the following error message:
java.lang.module.FindException: Module java.annotation not found, required by systems.uom.common
Investigation turns out, that the module description of 'systems.uom.common' contains this statement:
module systems.uom.common {
...
requires transitive java.annotation;
...
}
However, when printing the maven dependency tree via mvn dependency:tree for that module, we get:
[INFO] systems.uom:systems-common:jar:2.0.2
[INFO] +- javax.measure:unit-api:jar:2.0:compile
[INFO] +- tech.units:indriya:jar:2.0.2:compile
[INFO] | +- tech.uom.lib:uom-lib-common:jar:2.0:compile
[INFO] | \- javax.inject:javax.inject:jar:1:compile
[INFO] +- si.uom:si-quantity:jar:2.0.1:compile
[INFO] +- si.uom:si-units:jar:2.0.1:compile
[INFO] | \- jakarta.annotation:jakarta.annotation-api:jar:1.3.4:compile
[INFO] +- systems.uom:systems-quantity:jar:2.0.1:provided
[INFO] +- org.junit.jupiter:junit-jupiter-api:jar:5.5.2:test
[INFO] | +- org.apiguardian:apiguardian-api:jar:1.1.0:test
[INFO] | +- org.opentest4j:opentest4j:jar:1.2.0:test
[INFO] | \- org.junit.platform:junit-platform-commons:jar:1.5.2:test
[INFO] +- org.junit.jupiter:junit-jupiter-engine:jar:5.5.2:test
[INFO] | \- org.junit.platform:junit-platform-engine:jar:1.5.2:test
[INFO] +- org.junit.platform:junit-platform-launcher:jar:1.5.2:test
[INFO] \- org.junit.platform:junit-platform-runner:jar:1.5.2:test
[INFO] +- junit:junit:jar:4.12:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] \- org.junit.platform:junit-platform-suite-api:jar:1.5.2:test
I double checked all compile dependencies, if they do actually contain the module java.annotation, but they don't. (I did not explicitely check the test dependencies, because they are as far as I know not included when using UOM in your own application and should therefore not be taken into account when trying to resolve that strange module java.annotation).
That said: Where do you find that module java.annotation? I know of some modules javax.annotation, but not java.annotation. Furthermore, is this requires really needed? Recompile without that requires did work (in version 2.0.2 at least).
Other modules appear to contain this requires statement, too.
I think, I found the culprit: jakarta.annotation-api-1.3.4 has an automatic module name of java.annotation
Yes, that was probably still Jakarta EE 8, or it remained unchanged even in 9.0 which is why a few of those "Jigsaw" names may survive a little longer. It should be "jakarta.annotation" in the next versions.
Does the correct version of the JARs help solve the issue, then feel free to close the ticket?
The issue for us is indeed much more complicated. We are using some other modules as well, which in turn include the module com.google.code.findbugs:jsr305:3.0.2. However, that causes a package clash with jakarta.annotation:jakarta.annotation-api:1.3.4, because both of them contain the java package javax.annotation (disjunct packages). So we have started recompiling si-units with jakarta.annotation-api:2.0.0 and now I am trying to recompile systems-common with that same annotation-api version. However, I am getting a unit test failure now from the maven build (which is kind of off topic from this issue, but if anyone has a similar problem, this topic might be helpful):
[ERROR] Failures:
[ERROR] SystemOfUnitsServiceTest.testOtherUnitSystemServices:117 expected:<3> but was:<2>
So I am a bit stuck now. I don't know, if it is still a good idea to recompile against new jakarta:2.0.0 or maybe it would be a better approach to join jsr305 + jakarta:1.3.4 into a common jar (don't know if that would work, because jsr305 is defining the module javax.annotation with the package javax.annotation, but jakarta is defining the module java.annotation with the package javax.annotation).
First of all please try to use uom-systems 2.1 if you can, because the dependency chain looks quite old.
There was a reordering based on a different handling of priority (I recall the order was different by mistake) and later Indriya versions (you referenced 2.0.2 but in the Systems 2.1 chain at least 2.1.1 or even 2.1.2 should be used) fixed that.
I would say jakarta-annotations:2.0.0 plus jakarta-inject:2.0.0 is the future. They are independent of each other, but best combined although it might still happen that some third party dependency still uses the older versions especially with the DI JSR.
Just a short heads up. As suggested, we recompiled version 2.1 of si-units with jakarta:2.0.0 as well as systems-common with jakarta:2.0.0. However, one of the dependencies (indriya) has been compiled with Java 14 compiler, but sadly we are currently still stuck on Java 11 in our main application. We are currently doing a migration towards a newer Java Version, but that will take about two more weeks or so. I'll get back as soon as we can continue and verify.
Regarding this issue: Are there any plans to migrate towards jakarta:2.0.0 officially anyways? I could provide our changes with a pull request. Of course, the other project si-units would need parallel migration, too, but we can provide a pull request there, too.
If so, should we rename this issue to something like 'Migrate to jakarta.annotation-api:2.0.0'?
So, coming back after we finished migration to Java 17: Our manually recompiled versions of this project and si-units with the dependency towards jakarta 2.0.0 has been tested successfully.
So from my perspective I can offer two (and a half) options:
- Just close this issue
- Create a pull request with an updated dependency towards jakarta:annotation-api:2.0.0 and link to this (or maybe a new issue - that is the 'half' option).
I am happy with both outcomes, so just get back with what you like best.
I'd say for the next release a PR would be welcome if you can provide it, but maybe closing this and creating a new task to upgrade the dependency to Jakarta Annotations 2.0 might be cleaner.
Finally, I found the time. Created #196 and unitsofmeasurement/si-units#86
Closing this issue, because there is nothing left to do here.