OK fair point.
Therefore the fundamental question is not “How and When” but What will evolve?
So maybe the first step to answering the “what” is to go through each Java EE spec and give it a rating as to whether it will likely evolve in the future?
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Mark Little
Sent: 07 May 2019 13:18
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Our starting assumptions are clearly not the same.
The problem is, if you assume that the majority of Jakarta EE apis have a future and therefore need to evolve, then the namespace change has to occur. You are therefore already
in a cluster fsck.
Big Bang or incremental is not actually an irreversible decision.
If you start with the strategic goal that you are moving everything then it is possible to row back from that a little tactically at the individual spec level and platform level
based on new knowledge as the process continues.
If you start with the strategic goal that the impact of migrating each individual api needs to be individually assessed before making a decision then you are likely heading into
analysis paralysis.
Steve
From:
jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Mark Little
Sent: 07 May 2019 12:05
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
As Greg said in an earlier response, we shouldn't underestimate the effort this Big Bang will take and everyone involved in either the development of a Java EE application server,
a component of one(s) or someone leading one of the Jakarta EE specifications, should be requested to go and figure out the answer. What seems simple at the high level could become a complete cluster fcuk when examined in detail and given what the UK is still
going through with Brexit (yeah, I know!) I'd rather we made a decision based on all of the data so no one is surprised the day after the agreement is made and work has to start. We've spent 18+ months on Jakarta EE so far and adding a few more weeks to a
deadline isn't going to represent much of an extension to that but could help us all in the end.
I like the first proposal ("Big Bang"), I would propose we move everything, leaving some APIs under javax because they are unlikely to change unnecessarily ties our hands, in case
we do need to change something in them in the future.
[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:
-
The new namespace will be
jakarta.*
-
APIs moved to the jakarta namespace maintain class names and method signatures compatible with equivalent class names and method signatures in the javax.* namespace.
-
Even a small maintenance change to an API would require a
javax to
jakarta change of that entire specification. Examples include:
-
Adding a value to an enum
-
Overriding/adding a method signature
-
Adding default methods in interfaces
-
Compensating for Java language changes
-
Binary compatibility for existing applications in the
javax namespace is an agreed goal by the majority of existing vendors in the Jakarta EE Working Group and would be a priority
in their products. However, there is a strong desire not to deter new implementers of the
jakarta namespace from entering the ecosystem by requiring they also implement an equivalent
javax legacy API.
-
There is no intention to change Jakarta EE 8 goals or timeline.
-
Community discussion on how to transition to the
jakarta namespace will conclude
Sunday, June 9th, 2019.
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.
-
Some or all Jakarta EE APIs under
javax would move immediately into
jakarta as-is.
-
Any packages not moved from
javax to
jakarta could be included in Jakarta EE, but would be
forever frozen and never move to the jakarta namespace.
-
Jakarta EE 9 would be refocused as quick, stepping-stone release, identical to Jakarta EE 8 with the exception of the
javax to
jakarta namespace change and immediately released.
-
Jakarta EE 10 would become the new release name for what we imagined as Jakarta EE.next with only minor impact on timeline.
-
Work on Jakarta EE 10 could start immediately after rename is completed in the GitHub source and need not wait for the Jakarta EE 9 release to actually ship.
-
One-time coordination and cost to the industry, including; conversion tools, users, enterprises, cloud vendors, IDE creators, platform vendors, trainers and book authors.
-
Easily understood rule: everything Jakarta EE 8 and before is
javax, Jakarta EE 9 and after is
jakarta
-
Consistent with the
javax to
jakarta Maven groupId change.
-
Highest degree of flexibility and freedom of action, post-change.
-
Industry would have the opportunity to begin digesting the namespace change far in advance of any major new APIs or feature changes.
-
Largest upfront cost for
everyone.
-
Specifications that may never be updated would still likely be moved.
-
Decision to not move a specification is permanent and therefore requires high confidence.
-
Which specifications, if any, would we opt not to move?
-
Would we take the opportunity to prune specifications from Jakarta EE 9?
-
Do we change the language level in Jakarta EE 9 to Java SE 11 or delay that to Jakarta EE 10?
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.
-
The most active APIs would immediately move from
javax to
jakarta
-
APIs not changed or determined by the community to be unlikely to change would stay in
javax
-
Jakarta EE 9 would be a mix of
javax and
jakarta packaged APIs
-
If a change was needed to a
javax API post Jakarta EE 9 for any reason, that API would transition from
javax to
jakarta.
-
Jakarta EE 10 would be a mix of
javax and
jakarta packaged APIs, but a different mix than Jakarta EE 9.
-
At some point down the road, Jakarta EE xx, it may be decided that the migration from
javax to
jakarta is “done” and the final APIs are moved.
-
Cheaper up front cost and reduced immediate noise.
-
No need to move specifications unless there is an immediately visible benefit.
-
Potential for less impact from API change overall.
-
Prolonged coordination, cost and complexity to industry affecting conversion tools, users, enterprises, cloud vendors, IDE creators, platform vendors, trainers and book authors.
-
Use of restricted
javax namespace prolonged.
-
Frustration of “always changing” packages may deter application developers and become a permanent perception of the brand.
-
Difficulty in remembering/knowing which Jakarta EE release an API was moved. “Is Connector
javax or
jakarta in Jakarta EE 11?”
-
Difficulty in keeping the industry in sync.
-
New implementations may find themselves having to deal with the
javax to
jakarta transition, unable to avoid legacy costs and therefore decide not to enter the space.
-
Transitive dependencies to other specifications may make incremental change difficult or impossible.
-
Restrictions on what Java SE implementation can be used for certification
-
Do we start small or start large?
-
Which APIs would immediately need to be changed?
Out of Scope
The following are very important community discussions, but do not require a decision in the time-frame allotted:
-
Roadmap or release date for any Jakarta EE.next that would contain new features
-
List of specifications that may be deprecated, pruned or removed from Jakarta EE.next, if any
-
Specification text around backwards compatibility requirements, if any
-
What profiles should be defined
However, depending on the path chosen, some of these topics may require immediate resolution before the chosen path
can be executed.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|