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.adoc
we 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.
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
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
|