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.
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.
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...)
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 require Java 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.
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.
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