Settle on the Java SE version requirements for EE 10 profiles

[starksm64]

Is your feature request related to a problem? Please describe.
Yes, Java 11 has limped into support at the TCK level, but the language level requirements are still Java 8. By the time any EE 10 profile level specification is out, Java 17 will be the current LTS version of Java SE.

Describe the solution you'd like
We at a minimum update the base language level for EE 10 specifications to Java 11. A serious discussion about why Java 17 should not be the base level needs to be had as well.

Describe alternatives you've considered
None

Additional context
Java 8 SE support is on the decline and project are eager to move forward with newer language features.

[smillidge]

I'm happy with Java 11 language features.

Java 17 depends much on when EE10 is out. Close to 17 I think; 11 language features with 17 support as a requirement would fly.
A long time after 17 then 17 only features could be included.

[hantsy]

I think the Jakarta EE API syntax is Java 11 based.

But should consider the new Language feature support, as optional(activated when user is using the latest Java) , esp, Record, sealed class in JPA, JSONB, Bean validations etc.

Currently I have already used Record /Java 16 in my new projects.

[keilw]

Sounds fine. Since using at least Multi-Release-JAR up to ~Java 13 (which may never become a baseline, if we stick to the LTS ones like 8, 11 and 17) can be problematic due to some issues observed (and documented by the JDK issues like JDK-8207162) I would write some words of caution in the user or implementation guidelines or even the platform specification if better suited, but as a minimal version of a range that should ideally be 11-17.
I don't see a bigger problem with 11. And it could be too early for large enterprises (just a gut feeling from working with big clients) to switch to 17 across the board even if it's made available from around Q4/21 but they often have much slower test and release cycles for the JDKs they use, so 17 as a lower range sounds possible for EE 11 (the API if it's 11 already for Jakarta EE 10 may stay for a year or two unless it was better to go to the next LTS there, too?)

[keilw]

See #329 (comment) and below it, if it wasn't already suggested to have a range from Java 11 to 16 or better 17 (because that is the next LTS) it should because otherwise as rare as the situation may be (consuming at least one multi-release JAR while using module-info in your own target application) that could lead to compilation problems or even a compilation failure.

Parts of JUnit 5 use multi-release JARs, therefore many tests could be affected, and DKE-Data/agrirouter-sdk-java#146 hints, Log4J2 also uses MRJ, so some very popular libraries do, and I doubt those are the only ones.

[bstansberry]

I'm not particularly asking this with respect to EE 10, but the answer will inform how I feel about the minimum for 10.

Can this be a mix? IOW require a minimum and maximum source and binary level but do not require all specs to be on the same version within that mix.

A mix would mean a platform/profile implementation would be forced to the highest SE version in the mix of specs it supports. But it would not result in such a requirement on the implementations of the individual specs.

So, say in EE 11 some subset of specs wish to use SE 17 languages features. If a mix is allowed the other specs could use SE 11 as the source and binary level and therefore their impls could stay on SE 11. Server vendors could then have more flexibility in terms of their overall offerings; e.g. an SE 11-based server that is behind EE on some specs. And spec impls would have greater ability to support more than one version of the spec from the same codebase.

If that kind of thing wasn't possible and SE 11 was the base for EE 10 I'd be concerned that EE 11 would be another big-bang. A few specs wanting SE 17 language features would force the entire EE ecosystem off SE 11. If that were a likely possibility it's a good argument for moving to SE 17 in 10 and getting the big bang over with.

[starksm64]

I think it is inevitable that EE11 would allow for Java 17 language features and therefore effectively raise the minimum runtime to SE 17. I would guess that EE10 is going to choose a timebox that is at least two years, pushing EE11 into 2024 with a delivery in 2025/2026. AdoptOpenJDK and Red Hat list end of availability for SE 11 around Oct of 2024: https://adoptopenjdk.net/support.html https://access.redhat.com/articles/1299013 Oracle currently lists extended support until 2026: https://www.oracle.com/java/technologies/java-se-support-roadmap.html Those data points alone would indicate it does not make sense for EE11 to be on anything other than SE 17 as the base. That would be 4-5 years after SE 17 LTS is released. Having to wait that long for SE 17 language features is what some were complaining about on the platform call today. Specs could certainly run multiple major versions in parallel to allow for targeting both SE 11 and 17, and leave it up to the profiles to decide what SE level they will support. The problem is that if we are defining an SE level as part of the theme for a given EE platform timebox, then that is the minimum binary level specs need to support.

…

On Tue, Jun 1, 2021 at 7:30 PM Brian Stansberry ***@***.***> wrote: I'm not particularly asking this with respect to EE 10, but the answer will inform how I feel about the minimum for 10. Can this be a mix? IOW require a minimum and maximum source and binary level but do not require all specs to be on the same version within that mix. A mix would mean a platform/profile implementation would be forced to the highest SE version in the mix of specs it supports. But it would not result in such a requirement on the implementations of the individual specs. So, say in EE 11 some subset of specs wish to use SE 17 languages features. If a mix is allowed the other specs could use SE 11 as the source and binary level and therefore their impls could stay on SE 11. Server vendors could then have more flexibility in terms of their overall offerings; e.g. an SE 11-based server that is behind EE on some specs. And spec impls would have greater ability to support more than one version of the spec from the same codebase. If that kind of thing wasn't possible and SE 11 was the base for EE 10 I'd be concerned that EE 11 would be another big-bang. A few specs wanting SE 17 language features would force the entire EE ecosystem off SE 11. If that were a likely possibility it's a good argument for moving to SE 17 in 10 and getting the big bang over with. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#331 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRDMUUMKPOGQUUQSM4BGTTQV3TLANCNFSM43LJCHEQ> .

[anbusampath]

I'd be concerned that EE 11 would be another big-bang. A few specs wanting SE 17 language features would force the entire EE ecosystem off SE 11. If that were a likely possibility it's a good argument for moving to SE 17 in 10 and getting the big bang over with.

If it's possible moving on to Java SE 17 gives more reasons to migrate to Jakarta EE 10, even if we are not using language features running on Java 17 adds more values.

[bstansberry]

The problem is that if we are defining an SE level as part of the theme for a given EE platform timebox, then that is the minimum binary level specs need to support.

Are you referring here to Proposal 5 at https://docs.google.com/document/d/1ZQGEYSCN5eYtDjWOXAQqNin7iwLKHnQFEP73FDoQdbw/edit?pli=1#heading=h.pmflqhz4m8ch -- i.e. where the releases are very much oriented toward a particular SE version? If so, yes that kind of very strong theme would imply all specs must be compiled to the theme's SE level.

A less rigid theme wouldn't require that though. A release could require specs to support SE 17, including having a CI that passes TCK on SE 17, without requiring specs to compile to SE 17, which would then force impls to do the same, regardless of whether SE 17 was relevant to that spec/impl.

[starksm64]

I would say even Proposal 5 allows for what you are talking about, but the problem may be that other requirements like JPMS descriptors or incompatible changes like the removal of APIs/features that existed in the previous LTS release may cause an upgrade requirement in a spec even if they don't care about adding any new language features.

…

On Wed, Jun 2, 2021 at 1:15 PM Brian Stansberry ***@***.***> wrote: The problem is that if we are defining an SE level as part of the theme for a given EE platform timebox, then that is the minimum binary level specs need to support. Are you referring here to Proposal 5 at https://docs.google.com/document/d/1ZQGEYSCN5eYtDjWOXAQqNin7iwLKHnQFEP73FDoQdbw/edit?pli=1#heading=h.pmflqhz4m8ch -- i.e. where the releases are very much oriented toward a particular SE version? If so, yes that kind of very strong theme would imply all specs must be compiled to the theme's SE level. A less rigid theme wouldn't require that though. A release could require specs to support SE 17, including having a CI that passes TCK on SE 17, without requiring specs to compile to SE 17, which would then force impls to do the same, regardless of whether SE 17 was relevant to that spec/impl. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#331 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRDMTMWI4RY6ADBXIU2MTTQZYNRANCNFSM43LJCHEQ> .

[ivargrimstad]

Decision after discussion + vote on mailing list:

API source level: Java SE 11
API binary level: Java SE 11
TCK run with: Java SE 11+

[bstansberry]

Closing the loop on my previous comments, the exchange between BJ Hargrave and Kevin Sutter leading to https://www.eclipse.org/lists/jakartaee-platform-dev/msg02723.html addresses the concern I had.

[starksm64]

To wrap up this issue, the thread for the vote on the SE version is:
https://www.eclipse.org/lists/jakartaee-platform-dev/msg02650.html

The ballot summary spreadsheet is:
https://docs.google.com/spreadsheets/d/1Bu6IhGASVapXXaQix8HaED4JYx4UDj9eLEsjCP-7ddA/edit#gid=0

This was a contingent vote (https://en.wikipedia.org/wiki/Contingent_vote), and a summary of tally of votes amongst the 3 choices is provided below as a chart. The three choices were:

Opt1: Java SE 11 as source/language level and binary level for all API jars. Compatible implementations are free to pass TCKs using any Java SE version at 11 or higher.
 
Opt2: Java SE 11 as source/language level and Java SE 17 as binary level for all API jars. Compatible implementations are free to pass TCKs using any Java SE version at 17 or higher. Opt3. Java SE 17 as source/language level and binary level for all API jars. Compatible implementations are free to pass TCKs using any Java SE version at 17 or higher.
 
Opt3: Java SE 17 as source/language level and binary level for all API jars. Compatible implementations are free to pass TCKs using any Java SE version at 17 or higher.

The X axis in this chart gives the count of the first, second and third choices grouped by all votes, and committer only votes. The three bars in each section give the count for Opt1(green), Opt2(blue), Opt3(orange)

C1_all = the first choice tallies across all votes
C1_com = the first choice tallies for only committers
C2_all = the second choice tallies across all votes
C2_com = the second choice tallies for only committers
C3_all = the third choice tallies across all votes
C3_com = the third choice tallies for only committers

There were 36 votes in total, 12 committers, 24 non-committers. By the rules of the contingent vote, there was a clear majority of first choices for Opt1 regardless of whether committer votes counted or all votes counted, and so only the first choice votes needed to be considered.