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
For example, the current Maven coordinates for the Servlet jar are (
With Jakarta EE 8, these coordinates will change to:
The content of these 2 jars will be identical: both will contain
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
No other significant changes would be made (including not removing any deprecated methods or behaviours). This requires applications to update the package imports from
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
For example, if the Servlet 4.0 Specification is not updated, it will remain in the
However, if the Servlet Specification leaders decide to produce a Servlet 5.0 Specification, it will be in the
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 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
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 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
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
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
Standard-based deployments would be supported by adaption layers providing the servlet container and implementations would be provided for both
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
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-dev mailing lists. These discussions can be found below:
To provide feedback on the broader change from the
jakarta.* namespace, you can find a discussion on the jakartaee-platform-dev mailing list: