| I would probably suggest following a path similar to what we have done with Java EE in the past which is similar to your alternative 2.
- The initial release of Jakarta EE 9 and TCKs should be on the minimum version of Java SE to be supported for Jakarta Ee compatiblity, in this case Java SE 8 - Follow-up as soon as possible with an update release of the TCK(s) allowing support for the additional Java SE version(s) to be be supported.
As long as you have an implementation that can demonstrate Jakarta EE compatibility with the newer versions of Java SE, (it does not need to be Glassfish, in the event it is not ready to support say Java SE 11), then you can officially allow support for the new Java SE versions.
HTH
Best Lance
FYI, to get a wider
audience for this discussion, I posted to the following mailing lists:Platform: https://www.eclipse.org/lists/jakartaee-platform-dev/msg01987.htmlSpec Projec Leads:
https://www.eclipse.org/lists/jakartaee-spec-project-leads/msg00600.htmlThanks!
---------------------------------------------------
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:
Scott
Stark <starksm64@xxxxxxxxx>To:
jakartaee-tck
developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>Date:
07/07/2020
12:41Subject:
[EXTERNAL]
Re: [jakartaee-tck-dev] How to build the Platform TCK to target JDK8 but
support running with JDK11?Sent
by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
One reason was that Java 8 was to be
end of life at one point, but various vendors have extended its support.
Another reason was to start moving the platform to a more recent LTS version
that was post Java 9 in preparation to deal with JPMS issues.Note that Kevin will be sending out a
request to revisit the requirements for the Java SE version for EE 9, so
feedback should be directed to there so that plan can be updated one way
or another.On Tue, Jul 7, 2020 at 12:26 PM Gurkan
Erdogdu <cgurkanerdogdu@xxxxxxxxx>
wrote:I really don't understand why Java 8
is optional and 11 is a must. I think compatible implementations may support
JDK 8 or later versions. Why do we put such pressure on Java 11?On Tue, Jul 7, 2020 at 7:26 PM Scott
Stark <starksm64@xxxxxxxxx>
wrote:So frankly it is almost a useless statement
to say an EE9 runtime may certify against SE 8 as there is not sufficient
commitment to deliver TCKs that support that runtime. How would one even
submit a certification request when there is not likely to be a signed
TCK binary that they can reference as required by the certification process?
One or more parties would have to commit to delivering that for the
platform and all individual TCKs.On Tue, Jul 7, 2020 at 10:41 AM Scott
Marlow <smarlow@xxxxxxxxxx>
wrote:
On 6/30/20 3:39 PM, Kevin Sutter wrote:
> If
> Glassfish is not interested in Java 8, how are we going to determine
> whether the TCK is executable and testable with Java 8?
We will not be able to determine whether the final GlassFish 6.0 release
passes all tests on Java 8.
> Since the Java
> 8 compliance is optional, is this additional testing and verification
> required before we can claim Jakarta EE 9 is complete?
IMO, we need to question what it is that we want exactly.
1. One final EE 9 release that includes verification that the TCKs
are
executable and testable with Java 8 and Java 11.
2. A final EE 9 release that includes verification that the TCKs
are
executable and testable with Java 11 and a later (Platform 9.1.0 +
respective standalone) minor release that includes verification that the
TCKs are executable and testable with both Java 8 + 11.
> Or, do we wait
> until a vendor tries the Java 8 compliance testing and then work through
> the problems?
Good question, IMO, I think that option #2 above is better, but I defer
to conclusions to be made on platform mailing list discussion and/or
steering committee decisions.
With option #2, if we do come up with a way to test TCKs on Java 8 and
they pass 100% before EE 9 is final, then we will have achieved option
#1 in an unplanned way but that would be best (e.g. we will definitely
consume fewer Jenkins CI resources as well).
> This might get messy if we have to modify some tests
> after we go final with Java 11...
Yes, agreed. Also, with option #2 above, this will impact some of
the
community desire to start reorganizing the 5 million+ lines in the
Platform TCK for EE 10.
> I don't have all the answers. Just
> questions to think about and figure out before we claim Jakarta EE
9 is
> done...
Thanks Kevin for raising these questions!
Scott
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
_______________________________________________ jakartaee-tck-dev mailing list jakartaee-tck-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037Oracle Java Engineering 1 Network Drive Burlington, MA 01803Lance.Andersen@xxxxxxxxxx
|
