[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

Has a definitive decision on this been reached already? If not, when will it be reached? If a decision has been reached, can the community have visibility into how each of the stakeholders voted on this issue and why?

I looked at the recent meeting minutes and it is very unclear to me if a vote was held and what the rationale from each decision maker was. In particular I would personally like to understand how community input was weighted.

I am still hoping we can all celebrate together soon with the right forward looking and community focused decision being made by stakeholders.

Reza Rahman
Principal Program Manager
Java on Azure

Please note that views here are my own as an individual community member and do not represent the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: David Blevins <dblevins@xxxxxxxxxxxxx>
Date: 5/6/19 7:23 PM (GMT-05:00)
To: jakartaee-platform-dev@xxxxxxxxxxx
Subject: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

[Contents of this email represent discussions of the Jakarta EE Specification Committee over the last several meetings.  The statements here have been reviewed by and represent the voice of the Jakarta EE Specification Committee]

As announced in the Update on Jakarta EE Rights to Java Trademarks[1] post on Friday, future modification of the javax namespace will not be allowed.  While this is not what was envisioned when Jakarta EE started, in many ways this in our best interest as the modification of javax would always have involved long-term legal and trademark restrictions.

To evolve Jakarta EE, we must transition to a new namespace. The primary decisions we need to make as a community and industry are how and when. Given all delays and desires on everyoneâs part to move forward as fast as possible, we would like to have this discussion openly as a community and conclude in one month. It is the hope that in one month a clear consensus emerges and can be presented to the Specification Committee for final approval.

In an effort to bootstrap the conversation, the Specification Committee has prepared two proposals for how we might move into the new namespace. These should be considered a starting point, more proposals are welcome. No final decisions have been made at this stage.

The guiding principle for Jakarta EE.next will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.

Other proposals should incorporate the following considerations and goals:


It is envisioned binary compatibility can be achieved and offered by implementations via tooling that performs bytecode modification at either build-time, deploy-time or runtime. While there are open questions and considerations in this area, the primary goal of the discussion that must conclude is how do we move forward with future modifications to the APIs themselves.

Proposal 1: Big-bang Jakarta EE 9, Jakarta EE 10 New Features

The heart of this proposal is to do a one-time move of API source from the javax namespace to the jakarta namespace with the primary goal of not prolonging industry cost and pain associated with the transition.

Were we to take this path, a compelling approach would be to do the namespace rename and immediately release this as Jakarta EE 9. Additional modifications would be put into a Jakarta EE 10 which can be developed in parallel, without further delays.

Pros:
Cons:
Decisions:

Proposal 2: Incremental Change in Jakarta EE 9 and beyond

Evolve API source from javax to the jakarta namespace over time on an as-needed basis.  The most active specifications would immediately move in Jakarta EE 9.  Every Jakarta EE release, starting with version 10 and beyond may involve some javax to jakarta namespace transition.

Pros:
Cons:
Decisions:

Out of Scope

The following are very important community discussions, but do not require a decision in the time-frame allotted:


However, depending on the path chosen, some of these topics may require immediate resolution before the chosen path can be executed.

[1] https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/

-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852