+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/kevinwsutter
From:
John
Clingan <jclingan@xxxxxxxxxx>
To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:
06/05/2019
12:55 PM
Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Transitioning Jakarta
EE to the jakarta namespace
Sent
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.
Principal
Program Manager
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:
o
Adding
a value to an enum
o
Overriding/adding
a method signature
o
Adding
default methods in interfaces
o
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
Features
The
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 beyond
Evolve
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
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.
[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
_______________________________________________
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@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev