EOL (End of Life) for Eclipse Jetty 9, 10, 11 and CometD 5, 6, 7 - Update (Oct, 2025)

[jmcc0nn3ll]

This discussion topic is cross-posted from /issues/13918. General discussion should be kept here as much as possible.

Webtide is the company behind the open-source Jetty and CometD projects. For the last eighteen years, Webtide has fully funded the Jetty and CometD projects through services and support for migration assistance, production support, developer assistance, performance tuning, and CVE resolution.

Our approach to end-of-life (EOL) software has evolved as these open-source projects have continued to develop and innovate. With the recent Jetty 12.1 and CometD 9 releases, we must update the topic of EOL binary support.

Starting Jan 1, 2026, Webtide and the Jetty project will cease publishing releases for Jetty 9, Jetty 10, and Jetty 11 to Maven Central. Additionally, Webtide and the CometD project will cease publishing releases for CometD 5, CometD 6, and CometD 7 to Maven Central or other public repositories.

Actions

If you are currently using a non-EOL version of Jetty or CometD

No action is required at this time.

If you are currently using an EOL version of Jetty or CometD

Now is the time to plan an update to a publicly supported version of Jetty or CometD. Publicly supported versions like Jetty 12.1 and CometD 8 or 9 will continue to have bug fixes and CVE resolutions publicly available.

If upgrading is not an option and you are interested in binary support only, we are pleased to announce two current partnerships to meet your EOL needs.

• HeroDevs - NES for Jetty, NES for CometD (coming soon)
• TuxCare - ELS for Jetty, ELS for CometD

These partner products offer incredible value as they provide whole-stack security solutions, not only for Jetty and CometD but also for other popular open-source projects, such as Spring, that you may have as dependencies.

Backward Compatible Environments

Note that the application APIs from EOL versions are substantially maintained as environments within the current Jetty-12. Applications developed against EOL APIs should be able to be run on the latest Jetty version with minimal modification:

EOL Jetty	Jetty 12 Environment
Jetty 9	EE8
Jetty 10	EE8
Jetty 11	EE9

Full Support

If you are interested in a comprehensive solution, the Webtide Lifecycle Support program will continue to offer services and support for current and EOL Jetty and CometD versions.

Additional information will be available through the Jetty, CometD, and Webtide websites as updates roll out.

[openconcerto]

I hope I’m wrong, but this decision is heading in the wrong direction.
We’ll be among those getting off the train.

[jmcc0nn3ll]

What are you looking for support wise for EOL releases?

[gregw]

I hope I’m wrong, but this decision is heading in the wrong direction. We’ll be among those getting off the train.

@openconcerto Can you please explain why you think this is heading in the wrong direction?

This decision only effects versions that are EOL and many open source projects simply abandon those version and never update them, even for security issues. I've been working on Jetty for 30 years now and we have accumulated a lot of shared technical debt with our users. I have recently seen deployments of Jetty 5 and 6 in the wild! Jetty 8 are not uncommon and jetty 9.4 is still widely deployed. Add in 10 and 11 and that is a lot of EoL versions out there. It is simply not viable for a company like webtide to continue to offer free security updates for any EoL version that is out there. Some issues simply can't be fixed in old versions as often the security issue is a design and/or specification issue.

Webtide does offer commercial support for specific EoL versions of Jetty and we have previously publicly released EoL versions for which we have commercial support clients. However, this resulted in many commercial users of EoL versions riding on the coat tails of the few companies that are prepared to pay. This reduces the value of commercial support, reducing the number of commercial support clients and thus risking having any support at all for those versions. So we now have a mechanism for those that are dependent on EoL versions to share in the commercial support burden of EoL versions.

To our knowledge, there are no open source projects that are dependent on EoL versions of Jetty/Cometd. If there are, then please do open a discussion with us and we will help get those projects onto an openly supported version of Jetty/commetd.

There has never been a for-pay or "pro" version of a current Jetty/cometd release and there never will be. The project is fully open source. We just have some commercial offerings that help maintain EoL versions that would otherwise be abandoned or left to third party commercial support organisations to patch for their clients (they are open source after all).

[openconcerto]

(Long version)

Since 2002, we have been developing software in Java, all of it completely open source.
We are a French company slightly larger than Webtide, but not by much.
We are not customers of Webtide, but we financially contribute to the Eclipse Foundation, of which Jetty is a part.
Over the years, our team has reported a few bugs, shared ideas, and submitted patches.
The recent announcement about Jetty’s End of Life (EOL) concerns us, as the Cyber Resilience Act (CRA) will require software compliance and CE marking starting in September 2026.
Among other things, this includes obligations to report vulnerabilities and incidents. The CRA will also apply to Jetty.

Our use of Jetty (which began with Jetty 6)

We use AbstractHandler, SessionHandler, and WebSocket on Jetty 9.4.
And we use Servlet API 5.0 with the latest version of Jetty.

Jetty is used in embedded mode to simplify integration and facilitate profiling.
For performance reasons, we historically implemented AbstractHandler and SessionHandler directly.
Given Jetty’s significant internal changes, AbstractHandler and SessionHandler are no longer viable for us. We had to migrate to the Servlet API to become independent of the web server.

Version upgrades

Migrating from one major version of Jetty to another has always been a significant effort for us, days of work without necessarily gaining much.
A minor version upgrade takes about two days to validate all our uses (functionality and performance).

If developers don’t upgrade versions, it’s simply because there’s too much friction to do so.
As a result, your changes are creating our technical debt and pushing us to stay on end-of-life versions

Older versions of Jetty / EOL

Looking at the history of CVEs, fixes have never required major changes.
The closer you are to making these fixes for clients who purchase support, the more likely these changes will be made.
It could be shared at no cost to you.

Our experience

We observe that only a small fraction of our users subscribe to support for our applications,, but we continue to fix bugs and security issues in older versions. We gain customers this way.
Many users are willing to help, either by contributing to the Eclipse Foundation (as we do) or by purchasing complementary, less expensive products/services than full support.
For example, we publish a manual that sells hundreds of copies per year.
(if there were an official Jetty manual explaining how to get the most out of Jetty and its modules, I haven’t found it)

Our suggestions

Many companies (including ours) would be interested in simple (and therefore low-cost) services, such as:

• Rapid notification of CVEs
• Advance notice of approximate release dates for new Jetty versions and a preview of new features, to help plan upgrades.
• To be asked about the developments or features we would need

Personally, I believe the key is transitioning Jetty from one of the most widely used web servers to the most widely used web server.
This could be achieved through simple improvements, such as:

• A cookbook
• Easier to use HTTPS implementation (PEM import, hot-reloading certificates)
• Integration of dedicated authentication handlers (like TOTP)
• Log aggregation with the most widely used systems
• A JProfiler probe
• Relevant, production-ready examples to avoid spending hours dissecting code to find the right options.

Conclusion

This is why we will migrate to standards (Servlet API and JSR 356) to reduce our dependency on Jetty.

[jlouvel]

@jmcc0nn3ll @gregw Appreciate the great effort developing and maintaining Jetty through the years.

A few months ago we upgraded the support of Restlet in version 2.6 to Jetty 12.0. We removed our dependency with the Serviet API along the way which was nice as Restlet API offers an alternative abstraction (which btw isolates our users from internal design changes required by Jetty as you support new HTTP versions).

One popular OSS project I've been using recently is Apache Calcite and in particular its Avatica subproject which embeds Jetty 9.4 for remote JDBC server. I think it would be great if you could help upgrade it to Jetty 12. I'm happy to help on that front as well.

[joakime]

Some links ...

• Apache Calcite home page - https://calcite.apache.org/
• Apache Calcite source on Github - https://github.com/apache/calcite
• Apache Calcite issue tracker - https://issues.apache.org/jira/browse/CALCITE

I have an apache id, so I filed an issue with them.

• https://issues.apache.org/jira/browse/CALCITE-7284

[jlouvel]

Here is the related discussion: Jetty 12 upgrade in Avatica Sever-Apache Mail Archives https://lists.apache.org/thread/pz3fcwk1xcvh8opkj9gx0nd11gv03ql2

[gregw]

@jlouvel there is a lot to digest in your response.

We will probably take it one part at time. I'd like to respond to the pain of upgrading major versions....

This has definitely been the case historically as once you are not using the Servlet API we had little to distinguish Jetty APIs we consider internal vs those that we'd expect users to use. In recent releases we are making attempts to make that clearer.

But specifically, one of the key reasons of the jetty-12 release was to break apart the maintenance of the HTTP aspects and the application APIs. Specifically, we have the EE8, EE9, etc. environments now, that not only include the older servlet specifications, but the old jetty Handler API itself. Thus an application built on jetty Handlers will be able to upgrade from jetty-12, to 12.1 to 12.2 to 13 etc. whilst not being forced to update the application APIs used. As much as possible, we will keep the EE8... EEx environments backwards compatible with previous releases ("bug for bug compatible"), but you will be able to upgrade to the latest release with the latest real bug fixes and best HTTP implementation without changing your app.

Thus if you chose, it would be possible for you to keep your older jetty Handler implementations with minimal changes and run them on Jetty-12. It is also a reasonable decision to avoid Jetty APIs as much as possible and use Servlets, in order to reduce technical debt and to make any future change to an alternate (inferior :) web server.

One of the enablers for this change to EoL policy is precisely because of this backward compatible environment support in Jetty-12. There are no real technical reasons for a deployment to stay on Jetty-10 or Jetty-11. The only reason to stay on jetty-9.4 is if you are tied to Java8. So we are not abandoning users of old APIs, we are just giving them a better simpler supported platform (jetty-12+) to run those old apps on.

[jlouvel]

@gregw Thanks for the clarifications.

For the Restlet Framework that I'm helping maintain, we have already upgraded to Jetty 12 and have no remaining concerns as we still have an older version based on Jetty 9.4 and Java 8 available (even though it is EOL): https://github.com/restlet/restlet-framework-java/wiki/Releases

For the Apache Calcite Avatica project where I am only an end user, it seems more complicated due to the Java 8 requirement in Avatica currently. What do you recommend? Is there an option to make Jetty 12 core backward compatible with Java 8, and only those using the Jakarta EE 11 adapter would be required to use Java 17?