| Re: [jakartaee-platform-dev] Java 8 vs Java 11Compatibilityrequirements |
_______________________________________________That makes sense. I wonder, why some of it like
<properties>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.source>1.8</maven.compiler.source>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
Isn’t already enforced by a Parent POM instead of doing it in every spec/API Project (I took Injection as an example)?
Multi-release-JARs could allow to support new Features and still remain backward compatible with a Java 8 baseline, but I know first-hand this can be tricky, so I would not insist using it unless there really was a good reason.
module-info definitions already exist for some specs, mostly JSON, is there a reason why all API JARs shouldn’t at least do as JTA: https://github.com/eclipse-ee4j/jta-api or Servlet: https://github.com/eclipse-ee4j/servlet-api/tree/master/api which define an automatic-module-name, but is there a reason why both leave that at something like
<Automatic-Module-Name>java.servlet</Automatic-Module-Name>
while the actual module-info by all the JSON specs already changed to
"jakarta.json"?
Is there some logic behind that, or is it a technical debt which must be fixed before the Final release?
Werner
From: Kevin Sutter
Sent: Wednesday, July 8, 2020 00:39
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] Java 8 vs Java 11Compatibilityrequirements
The APIs need to be usable in a Java SE 8 runtime, just like the TCK. Customer environments are still populated with Java SE 8. Java SE 11 is making some inroads, but the majority are still using Java SE 8. Thus, the goal/requirement to support both Java SE 8 and 11.
You could use Java 11 for compiling as long as you generate the Java SE 8 byte codes.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Werner Keil <werner.keil@xxxxxxx>
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 07/07/2020 17:30
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Java 8 vs Java 11 Compatibilityrequirements
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
+1 Isn’t it enough, that they RUN with Java SE 8?
Especially JPMS (Jigsaw) support with a true module-info or multi-release JARs require that you run at least some parts of the build with Java 9, 10 or 11.
Btw, "the Java SE 8 source level" does not sound like you must use Java 8, only the POM has to be set accordingly.
Werner
From: Ryan Cuprak
Sent: Tuesday, July 7, 2020 23:41
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] Java 8 vs Java 11 Compatibilityrequirements
Hi,
Why is there the requirement that the APIs must be compiled with Java SE 8? I wouldn’t have thought that would be a requirement, hence my question.
Thanks,
-Ryan
On Jul 7, 2020, at 5:29 PM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Hi,
This topic has come up on our TCK mailing list (https://www.eclipse.org/lists/jakartaee-tck-dev/msg00785.html). The basic issue is that we *may* have a mismatch on our stated Java support statements and what can or will be delivered. I'd first like to explain the problem, and then suggest a couple of alternatives, and then ask for feedback. We need to make a decision by the end of this week (July 10). I'm moving this discussion to the Platform and Spec Project Leads mailing lists to get a wider audience.
The Jakarta EE 9 Release Plan (https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan) states this:
Java SE Version
For inclusion in Jakarta EE 9, specification’s APIs MUST be compiled at the Java SE 8 source level. However, compatible implementations of the Jakarta EE 9 Web Profile and Full Profile MUST certify compatibility on Java SE 11. Compatible Implementations MAY additionally certify and support Java SE 8.
Due to this "dual" compatibility requirement, the TCK is being built at the Java SE 8 byte code level.
Due to the stated MUST requirement of certifying on Java SE 11, Glassfish was going to move to being built at the Java SE 11 byte code level.
But, if we continue down that Java 11 only path for Glassfish, then we would not have an environment where we could prove compatibility with the Java SE 8 runtime. And, that would prevent us from successfully delivering Jakarta EE 9 since we need to demonstrate both the Required and Optional aspects of the Platform. (This is assuming that MUST==Required and MAY==Optional.)
We have been discussing a couple of alternatives.... Both of which would require an update to the Release Plan. We're looking for feedback to help figure out which approach provides the least impact and best experience for our customers.
Alternative 1:
TCK and Glassfish would be built at the Java SE 8 byte code level. The runtime for the execution of the TCK would be Java SE 11. We would requireJava 11 for certifying compatibility for Jakarta EE 9. We would notrequire compatibility testing with the Java SE 8 runtime. We would still have TCK Jenkins jobs running with Java SE 8 so that progress could be monitored, but proving that certification works with Java SE 8 would not be a requirement for releasing Jakarta EE 9.
(To be totally open, this was the alternative that I presented to the Steering Committee today. I was looking for a means of delivering Jakarta EE 9 without compromising the Jakarta EE 9 release plan too much. Basically, looking to soften the Optional requirement of the Java SE 8 runtime. During the course of the discussion, we came up with Alternative 2...)
Alternative 2:
TCK and Glassfish would still be built at the Java SE 8 byte code level. But, we would flip the release plan requirements... The runtime for the execution of the TCK would be Java SE 8. We would requireJava 8 for certifying compatibility for Jakarta EE 9. We would notrequirecompatibility testing with the Java SE 11 runtime. We would still have TCK Jenkins jobs running with Java SE 11 so that progress could be monitored, but proving that certification works with Java SE 11 would not be a requirement for releasing Jakarta EE 9.
(Background... Everything we released for Milestone 1 was with Java SE 8. We're already well on our way with the TCK effort. Moving Glassfish to Java SE 11 could disrupt our progress. Granted, we can hope for the best, but chances are moving to Java 11 will set us back a bit. And, since Java SE 8's Extended EOS date continues to move out (it's actually further out than Java SE 11), then maybe it makes more sense to stick with the proven environment.)
Note:
The subset of Java SE features that were dropped by Java 11 will still be provided via Jakarta EE 9. So, nothing else changes from a Release Plan content viewpoint. We're just looking for ways to mitigate some of the risks associated with certifying Glassfish with both Java SE 8 and Java SE 11.
Feedback welcome! Thanks!
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
_______________________________________________
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
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
