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
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
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
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.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.
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/
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
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
_______________________________________________
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
_______________________________________________
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