Skip to content
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

jakarta.activation-api is not a Multi Release JAR #122

Open
aalmiray opened this issue Feb 6, 2023 · 5 comments
Open

jakarta.activation-api is not a Multi Release JAR #122

aalmiray opened this issue Feb 6, 2023 · 5 comments

Comments

@aalmiray
Copy link

aalmiray commented Feb 6, 2023

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:

  1. 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

jbescos added a commit to jbescos/jaf that referenced this issue Feb 8, 2023
@jhanders34
Copy link

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?

@lukasj
Copy link
Contributor

lukasj commented Mar 21, 2023

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

@aalmiray
Copy link
Author

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.

@jhanders34
Copy link

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.

@lukasj
Copy link
Contributor

lukasj commented Mar 21, 2023

package info part of the problem is caused by a backward incompatible change in maven compiler plugin v 3.10.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants