The Issue

The Eclipse Jakarta EE project has not obtained the rights from Oracle to extend the Java EE APIs living in the javax.* package. As such, the Java community is faced with a choice between continuing to use the frozen javax.* APIs or transitioning to a new jakarta.* namespace where these specifications could continue to be evolved and/or significantly changed.
This name change is now a “fait accompli” (a.k.a. “done deal”), so it will happen no matter what. However, how the Eclipse Jakarta EE specification process handles the transition and how vendors like Webtide respond are yet to be determined.   
This blog discusses some of the options for how Webtide can evolve the Jetty project to deal with this renaming.

Jakarta EE Roadmap

Jakarta EE 8

A release of Jakarta EE 8 will happen first, and that will include:

• An update to Licensing
• An update to Naming (to limit the use of the trademarked term “Java”)
• An update to the Maven GroupID Coordinate Space in Maven Central
• No change to the Java packaging of the old Java EE 8 classes; they still retain their javax.* namespace.

For example, the current Maven coordinates for the Servlet jar are (groupId:artifactId:version):
javax.servlet:javax.servlet-api:4.0.1
With Jakarta EE 8, these coordinates will change to:
jakarta.servlet:jakarta.servlet-api:4.0.2
The content of these 2 jars will be identical: both will contain javax.servlet.Servlet.

Jakarta EE 9

The Eclipse Jakarta EE project is currently having a debate about what the future of Jakarta looks like. Options include:

Jakarta EE “Big Bang” Rename Option

Jakarta EE 9 would rename every API and implementation to use the jakarta.* namespace API.
This means that javax.servlet.Servlet will become jakarta.servlet.Servlet.
No other significant changes would be made (including not removing any deprecated methods or behaviours). This requires applications to update the package imports from javax.* to jakarta.* en mass to update possible dependencies to versions that use the jakarta.* APIs (e.g. REST frameworks, etc.) and recompile the application.
Alternatively, backward compatibility would be required (provided by Containers) in some form so that legacy javax.* code could be deployed (at least initially) with static and/or dynamic translation and/or adaption.
For example, Container vendors could provide tools that pre-process your javax.* application, transforming it into a jakarta.* application. Exact details of how these tools will work (or even exist) are still uncertain.

Jakarta EE Incremental Change

Jakarta EE 9 would maintain any javax.* API that did not require any changes. Only those APIs that have been modified/updated/evolved/replaced would be in the jakarta.* namespace.
For example, if the Servlet 4.0 Specification is not updated, it will remain in the javax.* package.
However, if the Servlet Specification leaders decide to produce a Servlet 5.0 Specification, it will be in the jakarta.* package.
 
 

The Current State of Servlet Development

So far, there appears very little user demand for iterations on the Servlet API.
The current stable Jetty release series, 9.4.x, is on Servlet 3.1, which has not changed since 2013.
Even though Servlet 4.0 was released in 2017, we have yet to finalize our Jetty 10 release using it, in part waiting for new eclipse Jakarta artifacts for the various EE specs, eg: servlet-api, jsp-api, el-api, websocket-api, and mail-api.  Despite being 2 years late with Servlet 4.0, we have not received a single user request asking for Servlet 4.0 features or a release date.
On the other hand, there has been interest from our users in more significant changes, some of which we have already started supporting in Jetty specific APIs:

• JPMS integration/support
• Asynchronously filter input/output streams without request/response wrapping
• Reactive style asynchronous I/O
• Minimal startup times (avoiding discovery mechanisms) to facilitate fast spin-up of new cloud instances
• Micro deployments of web functions
• Asynchronous/background consumption of complex request content: XML, JSON, form parameters, multipart uploads etc.

Jetty Roadmap

Jetty 10

Jetty 10, implementing the Servlet 4.0 Specification, will be released once the frozen Jakarta EE 8 artifacts are available. These artifacts will have a Maven groupId of jakarta.*, but will contain classes in the javax.* packages.
It is envisioned that Jetty 10 will soon after become our primary stable release of Jetty and will be enhanced for several years and maintained for many more. In the mid-term, it is not Webtide’s intention to force any user to migrate to the new jakarta.* APIs purely due to the lack of availability of a javax.* implementation.  Any innovations or developments done in Jetty 10 will have to be non standard extensions. 
However, we are unable to commit to long term support for the external dependencies bundled with a Jetty release that use the javax.* package (eg. JSP, JSTL, JNDI, etc.) unless we receive such commitments from their developers.

Jetty 11

Jetty 11 would be our first release that uses the Jakarta EE 9 APIs. These artifacts will have a Maven groupId of jakarta.* and contain classes also in the jakarta.* packages.
We are currently evaluating if we will simply do a rename (aka Big Bang) or instead take the opportunity to evolve the server to be able to run independently of the EE APIs and thus be able to support both javax.* and jakarta.*

Jetty Options with Jakarta EE “Big Bang”

If the Eclipse foundation determines that the existing javax.* APIs are to be renamed to jakarta.* APIs at once and evolved, then the following options are available for the development of future Jetty versions.
Note that current discussions around this approach will not change anything about the functionality present in the existing APIs (eg: no removal of deprecated methods or functions. no cleanup or removal of legacy behaviors. no new functionality, etc)

Option 0. Do Nothing

We keep developing Jetty against the javax.* APIs which become frozen in time.
We would continue to add new features but via Jetty specific APIs. The resources that would have otherwise been used supporting the rename to jakarta.* will be used to improve and enhance Jetty instead.
For users wishing to stay with javax.* this is what we plan to do with Jetty 10 for many years, so “Do Nothing” will be an option for some time. That said, if Jetty is to continue to be a standards-based container, then we do need to explore additional options.

Option 1. “Big Bang” Static Rename

Jetty 11 would be created by branching Jetty 10 and renaming all javax.* code to use jakarta.* APIs from Jakarta EE9. Any users wishing to run javax.* code would need to do so on a separate instance of Jetty 10 as Jetty 11 would only run the new APIs.
New features implemented in future releases of Jakarta EE APIs would only be available in Jetty 11 or beyond. Users that wish to use the latest Jetty would have to do the same rename in their entire code base and in all their dependencies.
The transition to the new namespace would be disruptive but is largely a one-time effort. However, significant new features in the APIs would be delayed by the transition and then constrained by the need to start from the existing APIs.

Option 2. “Big Bang” Static Rename with Binary Compatibility

This option is essentially the same as Option 1, except that Jetty 11 would include tools/features to dynamically rename (or adapt – the technical details to be determined) javax.* code usage, either as it is deployed or via pre-deployment tooling. This would allow existing code to run on the new Jetty 11 releases. However, as the Jakarta APIs evolve, there is no guarantee that this could continue to be done, at least not without some runtime cost. The Jakarta EE project is currently discussing backward compatibility modes and how (or if) these will be specified.
This approach minimizes the initial impact of transitioning, as it allows legacy code to continue to be deployed. The downside, however, is that these impacts may be experienced for many years until that legacy code is refactored. These effects will include the lost opportunities for new features to be developed as development resources are consumed implementing and maintaining the binary compatibility feature.

Option 3. Core Jetty

We could take the opportunity forced on us by the renaming to make the core of Jetty 11 independent of any Jakarta EE APIs.
A new modern lightweight core Jetty server would be developed, based on the best parts of Jetty 10, but taking the opportunity to update, remove legacy concerns, implement current best practices and support new features.
Users could develop to this core API as they do now for embedded Jetty usage. Current embedded Jetty code would need to be ported to the new API (as it would with any javax.* rename to jakarta.* ).
Standard-based deployments would be supported by adaption layers providing the servlet container and implementations would be provided for both javax.* and jakarta.*. A single server would be able to run both old and new APIs, but within a single context, the APIs would not be able to be mixed.
This is a significant undertaking for the Jetty Project but potentially has the greatest reward as we will obtain new features, not just a rename.

Jetty Options with Jakarta EE Incremental Change

These are options if the Eclipse foundation determines that the jakarta.*  package will be used only for new or enhanced APIs.

Option 4. Jakarta Jetty

This option is conceptually similar to Option 3, except that the new Jetty core API will be standardized by Jakarta EE 9 (which will hopefully be a lightweight core) to current best practices and include new features.
Users could develop to this new standard API. Legacy deployments would be supported by adaption layers providing the javax.* servlet container, which may also be able to see new APIs and thus mix development.

Option 5.  Core Jetty

This option is substantially the same as Option 3 as Jetty 11 would be based around an independent lightweight core API.
Users could develop to this core API as they do now for embedded Jetty usage. Standard-based deployments would be supported by adaption layers providing the servlet container and implementations would be provided for both javax.* and jakarta.*.

How You Can Get Involved

As with any large-scale change, community feedback is paramount. We invite all users of Jetty, regardless of how you consume it, to make your voice heard on this issue.
For Jetty-specific feedback, we have opened messages on both the jetty-users and jetty-dev mailing lists. These discussions can be found below:
https://www.eclipse.org/lists/jetty-users/msg08908.html
https://www.eclipse.org/lists/jetty-dev/msg03307.html
To provide feedback on the broader change from the javax.* to jakarta.* namespace, you can find a discussion on the jakartaee-platform-dev mailing list:
https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html