[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] [External] : Re: The location of module-info.java and muti release jar
|
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://urldefense.com/v3/__https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan__;!!ACWV5N9M2RV99hQ!atzdhdaFgbb1NcX8v_1DFK3PxT3sppUag_OQl5gChndEDLXidVtuPgM-p5ujZhiuKKk$>)
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://urldefense.com/v3/__https://github.com/eclipse-ee4j/injection-api/blob/master/pom.xml*L166__;Iw!!ACWV5N9M2RV99hQ!atzdhdaFgbb1NcX8v_1DFK3PxT3sppUag_OQl5gChndEDLXidVtuPgM-p5ujS6zsN1I$>).
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://urldefense.com/v3/__https://github.com/eclipse-ee4j/ejb-api/pull/141/files__;!!ACWV5N9M2RV99hQ!atzdhdaFgbb1NcX8v_1DFK3PxT3sppUag_OQl5gChndEDLXidVtuPgM-p5ujk6pva2c$> 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://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!atzdhdaFgbb1NcX8v_1DFK3PxT3sppUag_OQl5gChndEDLXidVtuPgM-p5ujDSsCfls$>
_______________________________________________
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://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!atzdhdaFgbb1NcX8v_1DFK3PxT3sppUag_OQl5gChndEDLXidVtuPgM-p5ujDSsCfls$>
_______________________________________________
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://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!atzdhdaFgbb1NcX8v_1DFK3PxT3sppUag_OQl5gChndEDLXidVtuPgM-p5ujDSsCfls$>
_______________________________________________
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://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!atzdhdaFgbb1NcX8v_1DFK3PxT3sppUag_OQl5gChndEDLXidVtuPgM-p5ujDSsCfls$>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!atzdhdaFgbb1NcX8v_1DFK3PxT3sppUag_OQl5gChndEDLXidVtuPgM-p5ujDSsCfls$
