BTW, I should mention that my comment was general in nature and not targeted specifically at Bill’s comment. I just wanted to insert my thought somewhere and that seemed as good a place as any :-)
+1, John. We
can start incrementally and move to big bang later. We can't do the
reverse.
--------------------------------------------------- Kevin Sutter STSM, MicroProfile and Jakarta EE architect e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter phone: tl-553-3620 (office), 507-253-3620 (office) LinkedIn: https://www.linkedin.com/in/kevinwsutterFrom:
John
Clingan <jclingan@xxxxxxxxxx>To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>Date:
06/05/2019
12:55 PMSubject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespaceSent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx I’ve been pretty quiet up to this point,
following the discussion. Early on was I was for “big bang” for various
reasons already outlined in other comments. What I find increasingly concerning,
the more I think about it, we are guessing/making assumptions as to the
impact of a decision. “We don’t know what we don’t
know”, IMHO. Making a big-bang change is a big step that could have unforeseen
consequences to the ecosystem and the user base. We are a small group discussing
the namespace issue that is trying to represent a developer base of probably
1M managing potentially millions deployed apps based on these specs. A
more conservative approach would be to do an incremental update, measure
the impact and learn some things along the way, and then decide if further
incremental steps are required or if we can simply move the remainder.On Jun 5, 2019, at 9:20 AM, Bill Shannon
<bill.shannon@xxxxxxxxxx>
wrote:Oracle agrees that
Big Bang is best. Steve Millidge
(Payara) wrote on 6/5/19 9:12 AM:Just to add Payara
favours a big bang approach as described in https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/namespace/proposal-01-bigbang.adocwe believe a majority of APIs need to evolve and therefore a majority of
apis will eventually move to the Jakarta namespace so may as well do it
now. From: jakartaee-platform-dev-bounces@xxxxxxxxxxx<jakartaee-platform-dev-bounces@xxxxxxxxxxx>On Behalf Of Scott Stark Sent: 05 June 2019 16:59 To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx> Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the
jakarta namespace There
has been no decision and there continues to be uncertainty as to the best
approach. Vendors seem to favor an incremental approach as there is a belief
that it eases backward compatibility stories. Developers seem to favor
getting the move over with. I think the current plan is to talk about a
plan toward a decision on the upcoming June 12 community call.
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 -------- Date:
5/6/19 7:23 PM (GMT-05:00) 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 javaxnamespace 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 javaxwould 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 javaxto jakartachange 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 javaxnamespace 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 jakartanamespace from entering the ecosystem by requiring they also implement
an equivalent javaxlegacy API.
- There is no intention
to change Jakarta EE 8 goals or timeline.
- Community discussion
on how to transition to the jakartanamespace 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 FeaturesThe heart of this proposal
is to do a one-time move of API source from the javaxnamespace to the jakartanamespace
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 javaxwould move immediately into jakartaas-is.
- Any packages not moved
from javaxto jakartacould be included in Jakarta EE, but would be foreverfrozen and
never move to the jakartanamespace.
- Jakarta EE 9 would
be refocused as quick, stepping-stone release, identical to Jakarta EE
8 with the exception of the javaxto jakartanamespace 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.
Pros:- 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
javaxto jakartaMaven 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.
Cons:- 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.
Decisions:- 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 beyondEvolve API source from
javaxto the jakartanamespace 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 javaxto jakartanamespace transition. - The most active APIs
would immediately move from javaxto 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 javaxand jakartapackaged APIs
- If a change was needed
to a javaxAPI post Jakarta EE 9 for any reason, that API would transition fromjavaxto jakarta.
- Jakarta EE 10 would
be a mix of javaxand jakartapackaged 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 javaxto jakartais “done” and the final APIs are moved.
Pros:- 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.
Cons:- 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 javaxnamespace 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 javaxorjakartain Jakarta EE 11?”
- Difficulty in keeping
the industry in sync.
- New implementations
may find themselves having to deal with the javaxto jakartatransition, 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
Decisions:- Do we start small or
start large?
- Which APIs would immediately
need to be changed?
Out
of ScopeThe 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.
[1]
https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ -- David Blevinshttp://twitter.com/dblevins http://www.tomitribe.com310-633-3852 _______________________________________________ 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
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|