If I had not put so many years behind this technology and didn't have the perspective of how many real people these decisions will touch, I would almost find some of this humorous. Instead of course it simply makes me sad.
We are twisting ourselves into knots around a simple truth - you need one simple, overarching solution for so many good reasons and so much effort was put into making Jakarta EE that solution - only to decide the whole thing maybe wasn't worth it and we need to invent yet another abstraction as a patch that prominently symbolizes our inability to come together for a common cause shared by all of our users and consumers.
Principal Program Manager
Java on Azure
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
For big bang approach, I think there is still one open question.
As per Bill's notes, " Big Bang proposal says "some or all" will be
moved to jakarta.*; it allows us to leave behind specs that we plan
this suggests further talk needs to happen for deciding the spec shortlist. I think the list needs to be refined first before the decision is made. I fear if big bang approach is chosen, we need more discussion to finalise the list. Further delay is unavoidable. One of the possible outcome is after a lengthy discussion, only 10-20 specs are to be maintained. This sounds incremental to me. I don't think a decision should be reached with open questions. Unless, Big Bang means migrating all specs.
With incremental approach, I think the roadmap is much clearer. Any specs can start evolving straight away.
Whatever we do we should close on a decision soon. Or we could be here still discussing it next year. I said at the start we need to consider as much data as possible to try to make an informed decision and I'm not seeing any new data coming in at this stage.
Option 1. you go incremental and if you realise you're screwed, you stop in this mid step can can't do anything. If you realise it works then you have to go through the pain by a thousand cuts.
Option 2. you go big bad and if you realise you're screwed, you stop or get this "fresh platform" with less conversion rate. If you realise it works, you've saved 999 cuts to your users
I also believe that Option 2 has a better chance of moving the ecosystem than Option 1, therefore a better chance of success.
Big Bang FTW.
On 5 Jun 2019, at 21:57, Bill Shannon wrote:
I continue to believe that the success of either approach will
depend on whether or not we have an effective binary compatibility
solution. So for me the fine print on my opinion is "assuming we
have a good enough binary compatibility solution".
If we start out with the incremental approach and find out that it
hurts too much, then what do we do? We can't go back. We have to
keep moving forward no matter what. Even if it means inflicting
pain at each release. So why not get it all over with at once.
Either way, I suspect many developers will skip these early releases
of Jakarta EE until these issues settle out.
Kevin Sutter wrote on 6/5/19 11:47 AM:
+1, John. We
can start incrementally and move to big bang later. We can't do
I’ve been pretty quiet up to this
following the discussion. Early on was I was for “big bang” for
reasons already outlined in other comments. What I find
the more I think about it, we are guessing/making assumptions as
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
consequences to the ecosystem and the user base. We are a small
the namespace issue that is trying to represent a developer base
1M managing potentially millions deployed apps based on these
more conservative approach would be to do an incremental update,
the impact and learn some things along the way, and then decide
incremental steps are required or if we can simply move the
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
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.
a definitive decision on this been reached already? If not,
when will it
be reached? If a decision has been reached, can the community
into how each of the stakeholders voted on this issue and why?
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
am still hoping we can all celebrate together soon with the
looking and community focused decision being made by
note that views here are my own as an individual community
member and do
not represent the views of my employer.
via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
[jakartaee-platform-dev] Transitioning Jakarta EE to the
[Contents of this
represent discussions of the Jakarta EE Specification Committee
last several meetings. The statements here have been reviewed
and represent the voice of the Jakarta EE Specification
As announced in
Update on Jakarta EE Rights to Java Trademarks post on
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
modification of javaxwould always have involved
long-term legal and trademark restrictions.
To evolve Jakarta
we must transition to a new namespace. The primary decisions we
make as a community and industry are how and when. Given all
desires on everyone’s part to move forward as fast as possible,
like to have this discussion openly as a community and conclude
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
the conversation, the Specification Committee has prepared two
for how we might move into the new namespace. These should be
a starting point, more proposals are welcome. No final decisions
made at this stage.
for Jakarta EE.next will be to maximize compatibility with
Jakarta EE 8
for future versions without stifling innovation.
incorporate the following considerations and goals:
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
change to an API would require a javaxto jakartachange of that
entire specification. Examples include:
value to an
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
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
to change Jakarta EE 8 goals or timeline.
on how to transition to the jakartanamespace will
conclude Sunday, June 9th, 2019.
It is envisioned
compatibility can be achieved and offered by implementations via
that performs bytecode modification at either build-time,
runtime. While there are open questions and considerations in
the primary goal of the discussion that must conclude is how do
forward with future modifications to the APIs themselves. Proposal 1:
Jakarta EE 9, Jakarta EE 10 New Features The heart of this
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
with the transition.
Were we to take
path, a compelling approach would be to do the namespace rename
release this as Jakarta EE 9. Additional modifications would be
a Jakarta EE 10 which can be developed in parallel, without
Some or all
EE APIs under javaxwould move
immediately into jakartaas-is.
from javaxto jakartacould be included
in Jakarta EE, but would be foreverfrozen and
never move to the jakartanamespace.
Jakarta EE 9
be refocused as quick, stepping-stone release, identical to
8 with the exception of the javaxto jakartanamespace change
and immediately released.
become the new release name for what we imagined as Jakarta
only minor impact on timeline.
10 could start immediately after rename is completed in the
and need not wait for the Jakarta EE 9 release to actually
and cost to the industry, including; conversion tools,
cloud vendors, IDE creators, platform vendors, trainers and
everything Jakarta EE 8 and before is javax,
Jakarta EE 9 and after is jakarta
javaxto jakartaMaven groupId
degree of flexibility
and freedom of action, post-change.
the opportunity to begin digesting the namespace change far
of any major new APIs or feature changes.
may never be updated would still likely be moved.
a specification is permanent and therefore requires high
if any, would we opt not to move?
take the opportunity
to prune specifications from Jakarta EE 9?
Do we change
level in Jakarta EE 9 to Java SE 11 or delay that to Jakarta
Change in Jakarta EE 9 and beyond Evolve API source
javaxto the jakartanamespace over time on
an as-needed basis. The most active specifications
would immediately move in Jakarta EE 9. Every Jakarta EE
starting with version 10 and beyond may involve some javaxto jakartanamespace transition.
would immediately move from javaxto jakarta
determined by the community to be unlikely to change would
stay in javax
Jakarta EE 9
be a mix of javaxand jakartapackaged APIs
If a change
to a javaxAPI post Jakarta
EE 9 for any reason, that API would transition fromjavaxto jakarta.
be a mix of javaxand jakartapackaged APIs, but
a different mix than Jakarta EE 9.
the road, Jakarta EE xx, it may be decided that the
migration from javaxto jakartais “done” and the
final APIs are moved.
and reduced immediate noise.
No need to
unless there is an immediately visible benefit.
impact from API change overall.
cost and complexity to industry affecting conversion tools,
cloud vendors, IDE creators, platform vendors, trainers and
changing” packages may deter application developers and
become a permanent
perception of the brand.
which Jakarta EE release an API was moved. “Is Connector javaxorjakartain Jakarta EE 11?”
the industry in sync.
may find themselves having to deal with the javaxto jakartatransition, unable
to avoid legacy costs and therefore decide not to enter
to other specifications may make incremental change
difficult or impossible.
Java SE implementation can be used for certification
Do we start
need to be changed?
of Scope The following are
important community discussions, but do not require a decision
in the time-frame
date for any Jakarta EE.next that would contain new features
that may be deprecated, pruned or removed from Jakarta
EE.next, if any
around backwards compatibility requirements, if any
on the path chosen, some of these topics may require immediate
before the chosen path can be executed.