|
+1
Based on experience in Jakarta EE projects I have not seen customers widely adopting Java 21 yet, while everything from 11 to 17 is commonly used now (as well as Java 8 still in some cases) Therefore restricting Jakarta EE 11 to Java 21 may turn away many possible
users who might wait till a later point before they use it or upgrade existing solutions.
Werner
From: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> on behalf of Emily Jiang via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
Sent: Wednesday, January 31, 2024 10:16 AM
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec] [BALLOT] Progress Review for Jakarta EE 11
+1 (IBM) with the following reasons:
1. Technical reason: None of the component specifications used any APIs from Java 21 including Jakarta Concurrency (Jakarta Concurrency does add one method for Virtual Thread, and this does not
depend on Java 21.) The Jakarta Concurrency TCK was written in a way that it can pass on either Java 21 or Java 17. Therefore, it makes more sense for EE 11 to support Java 17 and Java 21.
2. Business reason: In order to encourage the widest adoption of Jakarta EE 11, we think it is reasonable to broaden the scope to accommodate Java 17 and the broader set of implementations that
run on it. Different runtimes can choose which Java version they support, and this information can be clearly listed on the Jakarta EE compatibility website. It is no change from EE 10, which supports both Java 11 and Java 17.
Thanks
Emily
Greetings Jakarta EE Specification Committee,
I request your vote to approve and ratify the updated plan for Jakarta EE 11. This is a joint progress review for the Jakarta EE 11 Platform, Jakarta EE 11 Web Profile, and Jakarta EE 11 Core Profile specifications.
The JESP/EFSP requires a successful ballot of the Specification Committee to approve the plan of this release (as defined in the EFSP).
The relevant materials are available here:
The Jakarta EE Platform Project has provided the following motivation for the changes:
This change allows for several things while not restricting anything.
- It allows compatible runtimes to certify on Java SE 17 OR 21, while simultaneously allowing Concurrency to provide Java SE version runtime-aware support for Virtual Threads.
- It allows users who are not at liberty to run Java SE 21 to adopt Jakarta EE 11.
- It allows us to keep our delivery schedule of June/July 2024 to complete Jakarta EE 11.
Per the process, this will be a fourteen-day ballot, ending on Tuesday, February 13, 2024, that requires a Super-majority positive vote of the Specification Committee members (note that there is no veto). Community input is welcome, but only votes cast
by Specification Committee Representatives will be counted. According to the process, the ballot will conclude at the earliest on Tuesday, February 6 when all members have cast their vote.
The Specification Committee is composed of representatives of the Jakarta EE Working Group Member Companies (Fujitsu, IBM, Oracle, Payara, Tomitribe, Primeton Information Technologies, and Shandong Cvicse Middleware Co.), along with individuals who represent
the EE4J PMC, Participant Members, and Committer Members.
Specification Committee representatives, your vote is hereby requested. Please respond with +1 (positive), 0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated.
Thanks,
Ivar
--
Ivar Grimstad
Jakarta EE Developer Advocate |
Eclipse Foundation
Join Community
Day for Java Developers - October 16, 2023 (only €40)
EclipseCon
2023
- October 16-19, 2023
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
--
|
