My
thoughts on this are;
There is
only a small amount of tolerance out there for the pain of
migration from 1 release to another. The outline you have
below has the potential to require users of Jakarta EE 8 to
take a hit twice. First to migrate to Jakarta EE 9 as they
will have to port to Java 11 and cope with the loss of
deprecated apis they may be using. Then they will also face
a large migration effort to move to Jakarta EE 10. Many will
think we are signalling that the two step approach is the
best approach by having the two releases. I feel this will
drain goodwill.
I think
there are advantages to take the pain in one big hit as I
feel you can build a narrative that justifies this from the
points below.
First
Jakarta EE 8 will be released and that does provide backward
compatibility to Java EE 8 and will be supported by products
for many years therefore there is your continuity and LTS
version.
Second a
change forced upon us by lawyers to move the namespace to
Jakarta. Something we can only say once and is “our hands
are tied”. This point can also be expanded to cover why a
namespace drip change is worse than a big bang shift.
Third
there is the hit to move to Java 11 and all that entails
including full support for JPMS etc. in JakartaEE.Next
Fourth
the drive to reduce footprint and legacy for the Cloud
Native era justifies deprecating and removing a lot of old
apis.
Fifth to
increase innovation first by moving namespace this gives the
project teams space to innovate freely at the Eclipse
Foundation, secondly ditching legacy and backwards
compatibility provides the freedom for new players to enter
the market and new forms of runtime to be created.
Sixth
this will take time so JakartaEE.Next the next LTS is due
end of 2020(?) and time will also enable vendors to create
tools that will help users migrate to the latest LTS.
Finally
outline an LTS release strategy with intermediary releases
and a fixed cadence whereby Jakarta EE 8 is labelled as the
first LTS and put together a roadmap of future releases
which is compelling and says stick with us through this
journey as the future is exciting.
Steve
All,
I have been following this thread with great interest. I have
to admit that I am finding Steve Millidge's arguments about
biting the bullet and switching everything to the jakarta
namespace compelling. But at the same time breaking every
customer's existing Java EE application is a not to be done
lightly.
But I have noticed that there are some assumptions implicit
in what people are saying that should be discussed explicitly.
Those assumptions are basically about the overarching intent
of each of the Jakarta EE X releases.
I would like to throw out the following strawman proposal for
the main themes for the next couple of releases for your
consideration. Even if everyone thinks that this a completely
stupid idea, I do think that there is value is achieving
consensus at the level of release "themes" before continuing
the debate on release content. I was also say that I think
that it is at least plausible that some amount of parallel
development is possible with these suggestions.
Releases and themes
-
Jakarta EE 8: As soon as possible in 2019 (July/August?)
-
For all extents and purposes technically identical to Java
EE 8, but licensed under the Jakarta EE licensing regime,
rather than the JCP's.
-
Indicator of success is Payara (and ideally Apache TomEE
and others) are using the sailing ship logo.
-
Jakarta EE 9: TBC, but plausibly within 2019
-
Deprecate and remove unwanted APIs/specs following the
JESP process
-
Continue use of the javax namespace for the remaining
specifications, Likely the last release to ever make use
of javax.
-
Port to Java SE 11
-
Basically, this becomes the first Jakarta EE LTS release
-
Jakarta EE 10: TBC
-
Switch to jakarta namespace
-
Perhaps break backwards compatibility
-
Perhaps leverage some sort of application transformation
tool to map applications' use of javax to jakarta
If this approach were to be adopted, I would suggest that we
open Spec Projects for Jakarta EE 9 and 10 simultaneously in
late Q2.
Please adjust your phasers down to stun :)