For Jakarta 10 it would be a bit more simple to move on to Java 11 and stop providing Java 8 targeted classes (+module-info.class). How important (or large) is the group of developers that want the latest and greatest Jakarta spec version but are unwilling to move to a more modern Java version?
I've used the double compile approach to generate a proper module-info.class for a Java 8 project. As you say, this does help generate and validate a proper module-info.class, but I've found that doesn't always play nicely when in an IDE.
Tom
----- Original message -----
From: "Lukas Jungmann" <lukas.jungmann@xxxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: jakartaee-platform-dev@xxxxxxxxxxx
Cc:
Subject: Re: [jakartaee-platform-dev] [External] : Re: The location of module-info.java and muti release jar
Date: Thu, Oct 7, 2021 8:17 PM
On 10/7/21 9:39 PM, BJ Hargrave wrote:
> Some APIs may not want to step up to target Java 11 and will want to
> remain with target Java 8 for their API class files. In this case, they
> will need to compile module-info.java with target 11 and add that class
> file into the root of the jar. So there will be 2 compile steps in the
> build (one for module-info, and the other for the other classes).
My experience says having 2 complete compilations - first for everything
by 11, second everything minus module-info by 8 - is more reliable.
There were 2 sets of issues I faced when I was not following this:
1) java.lang.VerifyError (see
https://github.com/eclipse-ee4j/mail/issues/489 )
2) when module-info is compiled against pre-compiled classes, javac
won't issue warnings/errors for mistakes like missing "uses" and
probably others
...just saying...
thanks,
--lukas
> This is common practice in many projects. For example, see JUnit 5. All
> their jars have class files targeting Java 8 and also include a (target
> 11) module-info.class file in the root of the jar.
> A Java 8 runtime will not care about a module-info.class file in the jar
> and so will not attempt to load it. A Java 11 runtime will be able to
> load the module-info.class and the other target 8 class files just fine.
> That is, there is no need for the complexity of Multi-Release jars just
> to include a module-info.class file in a jar with other target 8 class
> files.
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and OSGi Specification Project lead // mobile: +1 386 848 3788
> hargrave@xxxxxxxxxx
>
> ----- Original message -----
> From: "Thomas Watson" <tjwatson@xxxxxxxxxx>
> Sent by: "jakartaee-platform-dev"
> <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
> To: jakartaee-platform-dev@xxxxxxxxxxx
> Cc:
> Subject: [EXTERNAL] Re: [jakartaee-platform-dev] The location of
> module-info.java and muti release jar
> Date: Thu, Oct 7, 2021 14:25
> If I understand the plan correctly
> (https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan
> <https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan>)
> I thought we are planning to produce API JARs for Jakarta 10
> that are at Java 11 source/target levels.
> With that said, I don't see why we would use multi-release JARs for
> any of the API JARs in Jakarta 10.
> Tom
>
> ----- Original message -----
> From: "Thiago Henrique Hupner" <thihup@xxxxxxxxx>
> Sent by: "jakartaee-platform-dev"
> <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
> To: "jakartaee-platform developer discussions"
> <jakartaee-platform-dev@xxxxxxxxxxx>
> Cc: "jakartaee-platform developer discussions"
> <jakartaee-platform-dev@xxxxxxxxxxx>
> Subject: [EXTERNAL] Re: [jakartaee-platform-dev] The location of
> module-info.java and muti release jar
> Date: Thu, Oct 7, 2021 12:43 PM
> What is possible to do is the following:
> Run the compilation two times: one targeting JDK 11, which will
> compile the module-info, and other targeting JDK 8, will
> override the classes built for JDK 11 with 8, and only the
> module-info will be there.
> I guess using Moditect is also possible.
> On Out 7 2021, at 2:38 pm, Scott Stark <starksm64@xxxxxxxxx> wrote:
>
> How can you produce a jar that can be read by Java SE 8
> unless it is multi-release? The comment there is talking
> about compiling under SE 11 which cannot be read at all by
> SE 8. The most basic class file compiled under 11 blows up
> when using 8:
> *└>
> **/Library/Java/JavaVirtualMachines/jdk1.8.0_261.jdk/Contents/Home/bin/java
> Hello*
> *Error: A JNI error has occurred, please check your
> installation and try again*
> *Exception in thread "main"
> java.lang.UnsupportedClassVersionError: Hello has been
> compiled by a more recent version of the Java Runtime (class
> file version 55.0), this version of the Java Runtime only
> recognizes class file versions up to 52.0*
>
> Sent from Mailspring
> On Oct 7, 2021 at 12:28:19 PM, Emily Jiang via
> jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>> wrote:
>
> Since we are on the topic of module-info, I observed
> different specifications doing different things as far
> as the location goes. Also, some spec produces
> multi-release jar such as Injection spec (see here
> <https://github.com/eclipse-ee4j/injection-api/blob/master/pom.xml#L166>).
> I was told some other specs just place module-info.class
> under root and do not produce a multi release jar as
> module-info.class will be ignored by Java 8 (the api jar
> compiled at Java 8). This is a cleaner way to do it.
> Can we define a convention for this? I know EJB is
> trying to add module-info as well and a long
> conversation is happening(see this
> <https://github.com/eclipse-ee4j/ejb-api/pull/141/files> PR).
> We really need to sort it out on the platform level.
> --
> Thanks
> Emily
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> <https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev>
>
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
