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 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
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 fromjavaxtojakarta.
· 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/
_______________________________________________
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