| Re: [jakarta.ee-spec] [BALLOT] Progress Review for Jakarta EE 11 |
|
-1 (Payara)
Our view is that changing the plan to have the Platform specification have Java 17 as its baseline target is a poor change.
The super-majority approved plan was for it to have Java 21 as its baseline. The argument that it will take more time to get the implementation into a state
where it can pass the TCK on Java 21 is not alleviated by the plan to allow certification against 17 or 21, as work would still have to be done to get it to pass on Java 21. Given that implementations aren't forced to compile on Java 21 and must just pass
the TCK using Java 21, this revised plan that requires ratifying implementations for both Java 17 and 21 (even if different) appears to only add work.
At this late stage Platform implementers would likely have already aligned and put into motion product plans for Java 21, and for there to suddenly be another
option for Java 17 that wasn't publicly on the table leaves a sour taste.
Setting Java 17 as the baseline but requiring ratification using 17 and 21 to provide user choice is also a positive spin on what we feel is actually just splitting
the specification. You will have "Type A" and "Type B" implementations of the Platform specification. We're adding extra migration hurdles that a user will have to tackle. We recently went through a large effort of removing optional parts of the Platform specification,
with this argument frequently coming up. Arjan brought up a nice example of the confusion that can occur for a user when specifications are loosened to appease implementations (the USB spec is not the only example of this that can be found).
The baseline of Jakarta EE being Java 17 is also not doing us any favours in combating the frequently touted view that Jakarta EE is old
and slow. Those waiting to update from EE 8 (or older) typically have a challenge in making the jump from Java 8 to 11. The challenge of going from Java 8 to 17 or 21 is comparable as to that of 8 to 11, and we want to encourage innovation, so we should push
implementations and adopters to utilise the latest features even if the specifications are themselves yet to make use of them.
Thanks,
From: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> on behalf of Ivar Grimstad via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
Sent: 30 January 2024 23:00 To: Jakarta specification disccusions <jakarta.ee-spec@xxxxxxxxxxx> Cc: Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx> Subject: [jakarta.ee-spec] [BALLOT] Progress Review for Jakarta EE 11 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.
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 |