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