Spec Committee –
I have discussed this briefly with Ed Bratt , Oracle’s rep on the Spec Committee and he and I are in agreement that this proposal is ill-advised. Ed will vote for Oracle on this ballot. The rest of the
comments below are mine, though I think Ed will generally agree.
I encourage all Spec Committee members to vote against this proposal. See my comments below.
Some process comments:
- The voting process requirements are misstated. The JESP requires that “Any modification to or revision of this Jakarta EE Specification Process, including
the adoption of a new version of the EFSP, must be approved by a Super-majority of the Specification Committee, including a Super-majority of the Strategic Members of the Jakarta EE Working Group, in addition to any other ballot requirements set forth in the
EFSP.” This should be clarified in the ballot mail.
- A modification to the JESP is one of the most important changes that could be made to Jakarta EE Working Group governance and process. Important governance
changes should be broadly socialized before being voted on, to maintain trust that adequate consideration is being given to significant proposals, and to give opportunity for community consideration and input on the change and its implications. That should
have occurred, and did not occur.
Some comments on the merits of the proposal:
- The implications of the proposal are unclear in important ways. The JESP should be very clear, and this modification does not meet the clarity bar:
- The proposal says: "All specifications must use the jakarta namespace". None of the existing Jakarta EE 8 specifications use the jakarta namespace.
What is the implication of the proposal for the existing Jakarta EE 8 specifications? Will they be declared no longer Jakarta EE Specifications? The JESP should not be ambiguous on such questions.
- There is an ongoing discussion with the MicroProfile Working Group about contributing MicroProfile specifications to the Jakarta EE Working Group.
Is the implication of this proposal that if another group, such as the MicroProfile Working Group, were to offer to contribute existing MicroProfile Specifications “as is” to the Jakarta EE Working Group, that the Jakarta EE Working group would refuse to accept
them? Does it make sense to impose broad restrictions on such contribution processes that have not been defined or thought through yet?
- I do not understand what the benefit of the proposal is. The proposal does not solve an immediate problem. Has anyone proposed a new Jakarta EE specification
that does not use the jakarta namespace? I don’t think we should change the JESP process without a clear benefit, or to solve spec process problems that do not yet exist.
- There may be cases that we have not considered where use of a “non-Jakarta namespace” in a specification would have some compelling technical or end
user or other benefit, and this resolution appears to preclude future consideration of such options. Let’s not preclude options that we may wish to exercise in the future without a compelling reason to do so.
- I am not directly familiar with all the opinions of all MicroProfile community members, but my guess is that the primary practical impact of adopting
the proposal would be to cause some percent of MicroProfile community members to view Jakarta EE more negatively, and to be more reluctant to contribute MicroProfile specifications to the Jakarta EE Working Group. I think this is a negative outcome.
I think the above is a LOT of negatives for a significant change to Jakarta EE Working Group governance and process. Better to think this through.
I encourage you to vote against this proposal
Thanks
Will
From:
jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> on behalf of Ivar Grimstad via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
Date: Thursday, June 12, 2025 at 3:38 PM
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
Subject: [External] : Re: [jakarta.ee-spec] [BALLOT] Update JESP to Clarify `jakarta` Namespace Requirements
Greetings Jakarta EE Specification Committee.
This is the ballot to action the proposal made in the 11th June Specification Committee meeting to update the text in the JESP to provide clarity on if the 'jakarta'
namespace is required or not.
The proposal is to clarify the Specification Committee stance and add the following text to the JESP: "All specifications must use the jakarta namespace".
Per the process, this will be a seven-day ballot, ending on the 19th of June 2025 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.
The Specification Committee is composed of representatives of the Jakarta EE Working Group Member Companies (Fujitsu, IBM, Oracle, Payara, Tomitribe, Primeton, 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.
|
|
Andrew
Pielage
Senior Software Engineer
|
|
|
|
|
Try our fully managed cloud native application runtime. 15 day trial available.
Payara.cloud
|
Payara Services Ltd, Registered office: Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ, United Kingdom
Registered in England and Wales: 09998946 | VAT: GB 193854467
|
|
|
|
|
Andrew
Pielage
Senior Software Engineer
|
|
|
|
|
Try our fully managed cloud native application runtime. 15 day trial available.
Payara.cloud
|
Payara Services Ltd, Registered office: Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ, United Kingdom
Registered in England and Wales: 09998946 | VAT: GB 193854467
|
|
|
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
--
Ivar Grimstad
Jakarta EE Developer Advocate |
Eclipse Foundation
Eclipse
Foundation - Community. Code. Collaboration.
|
