jakarta.activation-api is not a Multi Release JAR
Opened this issue · 5 comments
Describe the bug
Latest jakarta.activation-api (2.1.1
) includes 3 classes compiled to bytecode 53 and 44 classes compiled to bytecode 52. All classes are found in the unversioned space which means enforcer rules for both Maven and Gradle will trigger and fail a build.
To Reproduce
Steps to reproduce the behavior:
- Get jarviz
$ jarviz bytecode show --gav jakarta.activation:jakarta.activation-api:2.1.1
Unversioned classes. Bytecode version: 52 total: 44
Unversioned classes. Bytecode version: 53 total: 3
If the --details
flag is added you get the names of the 3 classes causing trouble
Unversioned classes. Bytecode version: 53 total: 3
jakarta.activation.spi.package-info
jakarta.activation.package-info
module-info
Expected behavior
These 3 classes should be inside /META-INF/versions/9
. The JAR's manifest should have a manifest entry such as Multi-Release: true
https://docs.oracle.com/javase/10/docs/specs/jar/jar.html#multi-release-jar-files
Activation 2.1 is part of Jakarta EE 10 so the classes all should be Java 11 byte code, i.e. version 55, shouldn't it?
Activation 2.1 is part of Jakarta EE 10 so the classes all should be Java 11 byte code, i.e. version 55, shouldn't it?
right, that is the requirement. OTOH we want mail, which depends on activation, to be able to support SE 8/Android
Normally I'd suggest using the moditect-maven-plugin to manage module-info.class
in such a way that it can be versioned while still keeping Java 8 compatibility. However, in this case there are 2 additional package-info.class
entries that are also compiled with Java 9.
IF these two additional classes must remain Java 9+ then moditect will be of little use. Instead, the build must be updated to support 2 source trees, probably add toolchains or expect the build to be invoked with a Java 9+ JDK as a requirement.
jaxb API had to deal with this as well: https://github.com/jakartaee/jaxb-api/blob/3.0.1/jaxb-api/pom.xml#L214 should help give some ideas on how to do it.
package info part of the problem is caused by a backward incompatible change in maven compiler plugin v 3.10.0