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
