[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] Java 8 vs Java 11 Compatibilityrequirements
|
Thanks, Werner, for
the customer perspective. That helps.
---------------------------------------------------
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/kevinwsutterFrom:
Werner
Keil <werner.keil@xxxxxxx>To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>Date:
07/08/2020
06:03Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Java 8 vs Java 11 CompatibilityrequirementsSent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
Running
the TCK I am not so worried about, because almost nobody needs to do that
aside from Vendors anyway, but if alternative 1 means Glassfish will no
longer work below Java 11, I am worried, that’ll drive people away from
evaluating Jakarta EE 9 in their companies or projects.
My
current customer is a very large bank and as committer rep I also represent
"end users”
or developers rather than vendors and while I can’t share most of the
internals Java 11 is at least a few years away from replacing Java 8 everywhere
especially in production.
The
only client project I saw and supported with Java 11 right from the start
was a) a green field project and b) an embedded environment, where the
JVM and everything else goes into a small box that looks a bit like a Raspberry
Pi, so they can replace the JVM when they replace the device, otherwise
it’ll stay probably for years, as well.
Glassfish
may not be relevant for production, but if companies consider using Jakarta
EE 9, they probably try it with Glassfish first before making a purchase,
unless they have an existing vendor dependency and could simply upgrade.
That
is made harder if they must upgrade to Java 11 just to get almost the same
functionality they had with Java EE 8 or Jakarta EE 8, so I would postpone
that step to Jakarta EE 10 if we can.
Werner
From:
Emily
Jiang
Sent: Wednesday, July 8, 2020 12:00
To: jakartaee-platform
developer discussions
Subject: Re: [jakartaee-platform-dev] Java 8 vs Java 11 Compatibilityrequirements
I
think alternative 1 is better as Jakarta EE9 is certified with the new
Java 11 and paves a good foundation for future development. This can test
the features dropped off by Java 11 are indeed provided by Jakarta EE9.
Besides, the runtimes can certify against Java 8 for their customers at
their own pace.
I
have some concern with alternative 2: how can we ensure all of the features
dropped off by Java 11 were added back to Jakarta EE9 without testing them
thoroughly? Besides, it still stays on an old version of Java while the
Java community is trying to move forward to Java 11, 14, etc.
Emily
On
Tue, Jul 7, 2020 at 10:30 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
--
Thanks
Emily
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev