There's
already some optional specs in Java EE 8, we could
remove them in Jakarta EE 9 and then not have to worry
about moving them to jakarta.*.
We could also consider pruning some other specs by
making them proposed optional in Jakarta EE 9 and
making them optional and possibly removing them in
Jakarta EE 10. Such specs might not need to be moved
to jakarta.*.
I think this is why the Big Bang proposal says "some
or all" will be moved to jakarta.*; it allows us to
leave behind specs that we plan to abandon.
But we haven't decided what our pruning or removal
policy will be for Jakarta EE releases so this may be
premature.
Steve,
> Are you really suggesting
that after all this time that we actually don’t
want to change the apis that we’ve just spent
two years moving to the Eclipse Foundation?
Not at all. I'm just being pragmatic.
It's very easy to talk about all of the desired
changes. It's another to get the community fired
up to actually architect, develop, test, and
document all of the changes. An incremental
approach would allow the more gradual (I'd say
natural) migration from javax to jakarta. It also
allows us to better determine which Specs are not
active and maybe candidates for stabilization or
deprecation or even removal.
---------------------------------------------------
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: "Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To: jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 06/05/2019
03:23 PM
Subject: [EXTERNAL]
Re: [jakartaee-platform-dev] Transitioning Jakarta
EE to the jakarta namespace
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
I’m
not aware of any list. The linked document is
Arjan’s view of what he wants to see. I’m sure
others would have other ideas. I for one would
want to see evolution of CDI, JBatch, JPA and
JMS and maybe even EJB which weren’t on the
list.
Now
that APIs have been moved to the Eclipse
Foundation whether an api evolves or not is up
to the open source project and the corresponding
community. However I firmly believe that for all
the mainstream heavily used Java EE 8 apis there
is a desire out there to see them evolve.
Are
you really suggesting that after all this time
that we actually don’t want to change the apis
that we’ve just spent two years moving to the
Eclipse Foundation?
Steve
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
:-)
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:
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/
_______________________________________________
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
_______________________________________________
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
