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
