We want
and need teams to move forward to the "jakarta"
namespace in Jakarta EE 9. That's where our focus is on
maintaining and enhancing the TCK bucket. But, we still
want to encourage the Jakarta brand by getting more TCK
compatible implementations -- whether it's for Jakarta
EE 8, or 9, or 9.1...
So,
maybe we should start with that question... What are
Webtide's plans on supporting Jakarta EE 9? Is Jakarta
EE 8 compatibility an "end game", or do you have plans
to move forward to Jakarta EE 9?
The Eclipse Jetty project has the following supported
versions currently ...
Jetty 9.4.x - Supports Java EE 7 / Servlet 3.1 /
javax.servlet / Java 8 - support until Java 8 interest
dies out (that means drop dead final possible year is 2030
which is the same end year as the super expensive support
contracts from oracle/azul/etc)
Jetty 10.0.x - Supports Jakarta EE 8 / Servlet 4.0 /
javax.servlet / Java 11 - this is our active mainline
development branch.
Jetty 11.0.x - Supports Jakarta EE 9 / Servlet 5.0 /
jakarta.servlet / Java 11 - this is our jakarta.*
namespace branch, and is essentially in lockstep
release/change/merge wise with Jetty 10.0.x
Future:
Jetty 12.0.x - Supports Jakarta EE 10 / Servlet ?? /
jakarta.servlet / Java ??
While we see adoption of Jetty 11 and jakarta.servlet
in many places, the fact that core/3rd-party (non-EE)
technologies have stated they are "never upgrading to
jakarta.servlet" is worrisome.
This means Jetty 9 (for Java 8 support) and Jetty 10
(for javax.servlet support) will be around and
be supported for a long time still.
The only thing we see as a "game changer" are some of
the tools (in active development) to convert
"javax.<spec>" usages to "jakarta.<spec>"
usages (statically and/or bytecode) before runtime.
The other pressures we see for adoption are things
outside of the control of the Jakarta EE project entirely,
such as key internet protocol changes/updates, and browser
changes forcing changes onto various specs (eg: TLS/1.3,
SameSite).
When enough of these kinds of changes occur, with an
ever increasing set of bandaged javax.<spec>'s will
force a change away from "javax.<spec>" as it
becomes too cumbersome to maintain anymore.
But what will people choose? jakarta.<spec>? or
some other technology (which they have a huge selection to
choose from today)?
- Joakim