| Re: [jakartaee-platform-dev] [jakartaee-spec-project-leads] Java 8vs Java 11Compatibilityrequirements |
Again from a customer, developer or DevOps point, it should not be too often. Most companies barely cope with the 2 Java SE Releases and the most recent Version I saw in Client Projects was Java 11, a large number will skip everything since and probably wait for the nex LTS (16 or 17?) if they even use Java 11 already. Others might go straight from 8 to 18 or above.
Not everyone can use the Cloud especially in Europe and many of the biggest companies got their own Cloud they Need to maintain because for safetey or other reasons they cannot use AWS, Google or Azure.
„Service Releases“ for Jakarta EE like a 9.1 or whatever to call them I guess that sounds reasonable, but I would not really think the market is able to handle a major Jakarta EE Version per quarter or even twice a year.
Werner
From:
reza_rahman
Sent: Thursday, July 9, 2020 05:47
To: JakartaEE
Spec Project Leadership discussions;
jakartaee-platform
developer discussions
Subject: Re: [jakartaee-platform-dev] [jakartaee-spec-project-leads]
Java 8vs Java 11 Compatibility requirements
In my opinion, a more rapid release cadence than Java EE is a key objective for Jakarta EE. I also agree that most people are still on Java SE 8. It would actually be even more impressive to have a Jakarta EE 9.1 release that features Java SE 11 support.
Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: kzr@xxxxxxxxxxx
Date: 7/8/20 9:47 PM (GMT-05:00)
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>, JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Subject: Re: [jakartaee-spec-project-leads] [jakartaee-platform-dev] Java 8 vs Java 11 Compatibility requirements
Kevin,
I mean Alternative #1.
I know September timeframe is important from the marketing viewpoint,
but I don’t think we should postpone Java 11 burdens to Jakarta EE 10 according to the big ban concept.
There may be another alternative if risk is high .
Alternative 1’:
Alternative 1 + slip the release date
-Kenji Kazumura
From:jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Kevin Sutter
Sent: Thursday, July 9, 2020 9:57 AM
To: JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Cc: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [jakartaee-spec-project-leads]
Java 8 vs Java 11 Compatibility requirements
Thanks,
Kenji,
Just trying to clarify your response since you mentioned the "move
to Java 11". Are you indicating the desire to have Glassfish
be compiled at the Java SE 11 bytecode level? If we go that route,
then Glassfish can not be the CI for Java SE 8 compatibility.
Or, are you meaning what I wrote for Alternative #1? Glassfish (and
the TCK) would be compiled at the Java SE 8 bytecode level, but Java SE
11 runtime would be the requirement to certify Glassfish for Jakarta EE
9. Java SE 8 would still be optional.
Even moving to the Java SE 11 runtime (keeping the Glassfish and TCK bytecode
levels at Java SE 8) introduces risk to the already aggressive plans.
---------------------------------------------------
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: "kzr@xxxxxxxxxxx"
<kzr@xxxxxxxxxxx>
To: "JakartaEE
Spec Project Leadership discussions" <jakartaee-spec-project-leads@xxxxxxxxxxx>,
jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 07/08/2020
18:35
Subject: [EXTERNAL]
Re: [jakartaee-spec-project-leads] Java 8 vs Java 11
Compatibility requirements
Sent by: jakartaee-spec-project-leads-bounces@xxxxxxxxxxx
Alternative 2 seems to be procrastination.
Sooner or later we have to move to Java 11.
The intent of big ban approach is mainly javax name space transitions,
but we should also finish the migration of Java 11 in Jakarta EE 9
in order to reduce the burden of incompatibilities in futures.
The reason why many of customers don't use Java 11 is a chicken and egg situation.
If Platform Specification does not move to Java 11 as default, nobody want to use Java 11.
In order to encourage both vendors and customers move to Java 11,
we should move to Java 11 as default in Jakarta EE 9.
-Kenji Kazumura
From:jakartaee-spec-project-leads-bounces@xxxxxxxxxxx
<jakartaee-spec-project-leads-bounces@xxxxxxxxxxx>
On Behalf Of Kevin Sutter
Sent: Wednesday, July 8, 2020 6:30 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>;
JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Subject: [jakartaee-spec-project-leads] Java 8 vs Java 11 Compatibility
requirements
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-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev