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
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.
Jun 5, 2019, at 9:20 AM, Bill Shannon <bill.shannon@xxxxxxxxxx>
agrees that Big Bang is best.
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.adoc
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
June 2019 16:59
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
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
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
I am still hoping we
can all celebrate together soon with the
right forward looking and community
focused decision being made by
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
Date: 5/6/19 7:23 PM
Jakarta EE to the jakarta namespace
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
in the Update on Jakarta EE Rights to Java
Trademarks post on Friday, future
modification of thejavaxnamespace
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
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.
principle for Jakarta EE.next will be to
maximize compatibility with Jakarta EE 8
for future versions without stifling
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
o Adding a
value to an enum
a method signature
default methods in interfaces
for Java language changes
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
discussion on how to transition to the jakartanamespace
will conclude Sunday, June 9th, 2019.
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
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
with the primary goal of not prolonging
industry cost and pain associated with the
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.
coordination and cost to the industry,
including; conversion tools, users,
enterprises, cloud vendors, IDE creators,
platform vendors, trainers and book
understood rule: everything Jakarta EE 8
and before is javax, Jakarta EE
9 and after is jakarta
with the javaxto jakartaMaven groupId
degree of flexibility and freedom of
would have the opportunity to begin
digesting the namespace change far in
advance of any major new APIs or feature
upfront cost for everyone.
that may never be updated would still
likely be moved.
· Decision to
not move a specification is permanent and
therefore requires high confidence.
specifications, if any, would we opt not
· 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
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
· The most
active APIs would immediately move from javaxto jakarta
font-weight: normal; font-stretch:
normal; font-size: 7pt; line-height:
normal; font-family: "Times New