jakarta.mail-api is not a Multi Release JAR

[aalmiray]

Describe the bug
Latest jakarta.mail-api (2.1.1) includes 6 classes compiled to bytecode 53 and 148 classes to 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.mail:jakarta.mail-api:2.1.1 
Unversioned classes. Bytecode version: 52 total: 148
Unversioned classes. Bytecode version: 53 total: 6

If the --details flag is added you get the names of the 6 classes causing trouble

Unversioned classes. Bytecode version: 53 total: 6
jakarta.mail.search.package-info
jakarta.mail.util.package-info
jakarta.mail.event.package-info
jakarta.mail.internet.package-info
jakarta.mail.package-info
module-info

Expected behavior
These 6 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]

It looks we have the same issue we had here, and I bet this is a problem in many other projects:
eclipse-ee4j/parsson#73

I will apply the same fix.

We don't need a multirelease, right?. package-info.java can be compiled with release 8 with no issues.

[FredDietrich]

What about module-info.class? It can neither be compiled nor ran with jdk/runtime 8. So the problem is only partially fixed with the package-info job?

Also, would (and could) this be ported over to 1.x? Asking because in need of multiline POP3 xoauth2 authentication, but, stuck to pre-jakarta mail (1.6.2) because of the classes compiled with 53 major version.

[jbescos]

This can be addressed here.

It looks we will not compile with JDK 8 anymore, everything will be compiled for JDK 9 or 11, and we don't need a multirelease for module-info.

[aalmiray]

FWIW you would still need a multi-release JAR if classes compiled with multiple bytecode levels find their way into the JAR, as noted the enforcer plugins check compliance to a given level in the whole unversioned classes space.

This is not a Java 8 only thing.

[jbescos]

FWIW you would still need a multi-release JAR if classes compiled with multiple bytecode levels find their way into the JAR, as noted the enforcer plugins check compliance to a given level in the whole unversioned classes space.

This is not a Java 8 only thing.

The idea is to compile everything with JDK 11, so we will not need a multirelease jar.