Baseline Java SE level for EE 11

[starksm64]

Is your feature request related to a problem? Please describe. We need to define the minimum language level of Java SE to use for the EE 11 release.

Describe the solution you'd like The minimum runtime needs to be defined with an open ended upper bound

Describe alternatives you've considered The Oracle Java SE Support Roadmap has the following recent and near term LTS targets:

LTS Release	GA Date	Initial EOL
11	September 2018	September 2023
17	September 2021	September 2026
21	September 2023	September 2028

11 seems a non-starter as it begins EOL ramp-down in the timeframe of an EE 11 release.

Additional context EE 10 Java SE discussion TBD

[anbusampath]

If Jakarta EE 11 is going to take another 15-18 months to get released. Java 21 makes more ideal choice for EE 11 baseline.

[hantsy]

Still use SE 11 as baseline(update API, Impl, and TCK, Glassfish to use the latest SE 11 syntax). Also consider the new features introduced since SE 11, such as Record, sealed classes etc. And I would use multiversion Java(11, 17, 21) build for the further Jakarta EE.

And currently there are a lot of features in SE 11 that are not applied in Jakarta EE 10, such as HttpCLient(eg. add body handler to resolve json using JSONB, JSONP, etc), Flow(ReativeStreams) API(as an alternative of the sync API), etc.

Regards,

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker

GitHub: https://github.com/hantsy

Twitter: @.*** Medium: @.***

On Mon, Oct 10, 2022 at 2:16 AM Anbu Sampath @.***> wrote:

If Jakarta EE 11 is going to take another 15-18 months to get released. Java 21 makes more ideal choice for EE 11 baseline.

— Reply to this email directly, view it on GitHub https://github.com/eclipse-ee4j/jakartaee-platform/issues/553#issuecomment-1272599759, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGQT6HBN6SM5KY6MEFRQJ3WCMDY7ANCNFSM6AAAAAAQXBU6WA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[smillidge]

Steering committee is also considering this question as part of the narrative for EE 11 as it also ties heavily into release cadence/ release date. This will go to a committee vote soon current options developing are;

Q4 2023 12 months ( 1 year cadence) - JDK 17 Q1 2024 Java LTS + 6 months (then a 2 year cadence) - JDK 21 Q4 2024 24 months (2 year cadence) - JDK 21

[cesarhernandezgt]

I think Java 11 should be included in the equation since vendors [1] other than Oracle are also showing initial EOL support until 2026/2027. Just the latest update over Java SE 8 shows 2030.

I think setting a higher baseline like JDK 21 can reduce the adoption of end-users for Jakarta EE 11.

Also the 2022 Jakarta EE Developer Survey Report shows that Java 11 is still relevant:

Despite being released less than a year ago, use of Java 17 (the LTS release of Java SE) has surged to 26%. Java 11 use remains steady at 57% (58% in 2021).

From a Java SE feature point of view, I +1 the proposal Scott made via https://github.com/eclipse-ee4j/jakartaee-platform/issues/561 to collect feedback from specification projects about what they expect to target for EE 11. This will provide more information to have an assertive Java SE baseline for EE 11.

[1] https://www.azul.com/products/azul-support-roadmap/ https://bell-sw.com/roadmap/ https://aws.amazon.com/corretto/faqs/

[aeiras]

Hola and happy/healthy 2023 @starksm64! :)

Is there a plan to send this issue to the platform mailing list? There are only 47 watchers on this repo... lacking proper exposure IMO. Thank you for starting the public discussion.

[hantsy]

I would like to use Java 17 as a baseline of the next Jakarta EE 11. Java 17 is used widely in Java communities, maybe some cloud vendor/frameworks/libs are still using the older Java 8/Java 11, but Spring 6/Spring Boot 3 has already upgraded to Java 17, and Quarkus and Micronaut also consider Java 17 as baseline in the next major versions. Java 17 will be the mainstream soon.

Since Java 11, there are a lot of new language-level features introduced in Java 17, when a developer is using the new Java, but face the problems, the new features are not supported by specs. For example, JSON serialization and bean validation support on a record object is completely dependent on the providers. If a developer is using Java 17(personally I have used Java 17 over one year in real projects) and the spec does not support the awesome features in Java 17, he have to find some solutions included in some libs/frameworks and give up Jakarta EE.

At the same time, when using the latest Java 17 LTS, Jakarta EE specs themselves can use the new syntax to simplify the APIs.

And also consider Record, sealed interfaces/classes in the new API design.

---

Regards,

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker

GitHub: https://github.com/hantsy

Twitter: @.*** Medium: @.***

On Wed, Jan 4, 2023 at 5:59 AM Amelia Eiras @.***> wrote:

Hola and happy/healthy 2023 @starksm64 https://github.com/starksm64! :)

Is there a plan to send this issue to the platform mailing list? There are only 47 watchers on this repo... lacking proper exposure IMO. Thank you for starting the public discussion.

— Reply to this email directly, view it on GitHub https://github.com/eclipse-ee4j/jakartaee-platform/issues/553#issuecomment-1370266866, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGQT6DKAJ7BM6P5Q7NTA5LWQSOLDANCNFSM6AAAAAAQXBU6WA . You are receiving this because you commented.Message ID: @.***>

[dmatej]

Yet one note about statistics and feedback - people who already abandoned JEE don't provide any feedback. They are simply gone and we have to prove that JEE is modern and sustainable in long term. Then they would consider to go back to us. So all feedbacks are biased.

JDK 11 is a dying horse now, people demanding it's support often want also support of GlassFish 6, not GF7+. We need to make migrations easy, well documented, testable, but not to try to conservate the state.

Also JDK8/11 leads to wrong assumptions in our code, which then doesn't work on production with newer Java versions. Reflections, module-info, modules, all these things significantly changed between 11 and 17 and they are the more visible the more far you are from the library, ie. when you use ear module with wars and jars inside, osgi, and at the bottom is some JEE jar file. Unit tests are unable to detect these issues because they see everything. But the TCK tests will, and newer JDK versions are more strict.

Finalizers will be gone, Security Manager will be gone, etc.

If there is a demand for the support of older JEE releases, it is alright, but someone has to do it and pay for it. Main JEE development should be driven by sustainable, maintainable modernization, not by nostalgia.

[smillidge]

Steering committee resolution yesterday was to recommend 21 as a baseline for Jakarta EE 11 with a target GA date of Q1 2024.

[hantsy]

Oh, it seems the Jakarta EE 11 is still in progress, I can not find a confirmed feature list till now.

But JDK 21 will be released soon.

If Jakarta EE 11 is released in 2024 or later, use Java/JDK 21 directly.

[ivargrimstad]

Oh, it seems the Jakarta EE 11 is still in progress, I can not find a confirmed feature list till now.

But JDK 21 will be released soon.

If Jakarta EE 11 is released in 2024 or later, use Java/JDK 21 directly.

The current plan is to release Jakarta EE 11 in Q1, 2024 with Java SE 21 as a baseline

[hantsy]

Oh, Java 11 -> Java 21 is a big jump. We have a lot of features in Java SE 21 should be considered in Jakarta EE now.