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.
Kevin Sutter wrote on 6/5/19 1:37 PM:
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 [1]
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
FROM:jakartaee-platform-dev-bounces@xxxxxxxxxxx
<jakartaee-platform-dev-bounces@xxxxxxxxxxx> ON BEHALF OF John
Clingan
Sent: 05 June 2019 20:54
To: jakartaee-platform developer discussions
<jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to
the jakarta namespace
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 :-)
@Steve, you mentioned "we believe a majority of APIs need to
evolve”. Does a list exist of which APIs plan to evolve and in
what timeframe? I think the only list I’ve seen is here:
https://www.eclipse.org/community/eclipse_newsletter/2019/february/Jakarta_EE_9.php
[2]
On Jun 5, 2019, at 11:47 AM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
+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 [1]
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.adoc
[3]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.
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.
On Jun 5, 2019, at 4:19 AM, reza_rahman <reza_rahman@xxxxxxxxx>
wrote:
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 --------
From: David Blevins <dblevins@xxxxxxxxxxxxx>
Date: 5/6/19 7:23 PM (GMT-05:00)
To: jakartaee-platform-dev@xxxxxxxxxxx
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/
[4]
--
David Blevins
http://twitter.com/dblevins [5]
http://www.tomitribe.com [6]
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 [7]
_______________________________________________
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 [7]
_______________________________________________
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 [7]
_______________________________________________
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 [7]
_______________________________________________
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 [7]
_______________________________________________
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 [7]
_______________________________________________
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
Links:
------
[1] https://www.linkedin.com/in/kevinwsutter
[2]
https://www.eclipse.org/community/eclipse_newsletter/2019/february/Jakarta_EE_9.php
[3]
https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/namespace/proposal-01-bigbang.adoc
[4]
https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/
[5] http://twitter.com/dblevins
[6] http://www.tomitribe.com/
[7] 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
