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.

This topic updates the statements made in previous EOL issues for Eclipse Jetty and CometD.

• EOL (End of Life) for Jetty 9 - January 2025 #7958
• EOL (End of Life) for Jetty 10 / Jetty 11 - January 2025 #10485
• Announcement of End of Community Support for CometD 5.0.x cometd/cometd#1179
• Announcement of End of Community Support for CometD 6.0.x & 7.0.x cometd/cometd#1754

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.

[gregw]

Creating a version of jetty-12.1/EE8 that runs on java-8 is feasible. But, it is not something that we have had time to do, no any interest from commercial clients.

However, once this new policy gives us we fewer branches of Jetty to actively maintain, we may have more cycles to look at such variant. I've created #14029 to track interest/thoughts/demand/contributions to this idea. Of course, community contributions and/or commercial sponsorship would also increase the probability of such a branch.

[openconcerto]

Your point on technical debt is somewhat surprising.

Technical debt refers to the future costs associated with relying on shortcuts or suboptimal decisions made during software development.
Even if Jetty 12 is an improved version of Jetty 9.4 and introduce features such as HTTP/3, why should Jetty 9 automatically be considered outdated, suboptimal, or flawed?
As for today, Jetty 9.4 is perfectly running on current hardware and operating systems. It's perfectly compatible with others webservices and web browsers.
In our software, it has been running continuously for years with the expected performance and compatibility.

Jetty 9.4 has simply become, overnight and arbitrarily, a version of Jetty that must no longer be used under the threat of receiving no further security fixes. By definition, this makes it incompatible with future European requirements.
I see no reason to believe that things will be any different with Jetty 12 once Jetty 13 is released.

I fully understand that behind all of this lies your intention to secure greater financial resources.
As I mentioned earlier, the key is to increase Jetty’s market share by offering affordable services (or complementary products) and advanced features (as listed above), rather than working against users’ long-term needs for stability and security.

[gregw]

@openconcerto Jetty-9.4 has long been EOL, so there is no abrupt change in status. There have never been any guarantee that CVEs or other issues in EOL releases would be fixed, as they are in fact EOL. The only reason that there have been fixes for some EOL versions is because there are some commercial clients on those EOL releases. But that number is shrinking over time as we assist our support clients to migrate to jetty-12 and beyond. This policy change is offering an option at lower cost than full support to keep these branches maintained. Hopefully these EOL branches may end up having a longer life by sharing the smaller cost among many commercial users rather than relying on the largess of a shrinking few.

We do not believe this is incompatible with future European requirements. We are providing a support path for legacy Jetty applications by providing the backward compatible APIs in the EE8/EE9/etc. environments of Jetty-12 and beyond. For more than that, we are offering commercial services to provide support to commercial users of specific EOL versions. In fact, those very laws are saying that companies that do have products based on EOL versions of a project should engage in a program like we are offering in order to meet those very requirements, as it is not sufficient for them to just assume EOL version will be maintained forever.

Jetty-12 will indeed ultimately become EOL when Jetty>=13 is released and stable. But the key point is that Jetty-13 will continue to have the backward compatible environments such as EE8, EE9 etc. Thus we will continue to support legacy APIs by providing an up to date runtime that can deploy them. We are not ending support for legacy jetty applications as we are actively supporting them by support those APIs in the current active releases and it is our intention to continue to do so.

Finally do note that services like those offered by our partners Tuxcare and Herodevs only exist because there are many many EOL versions of open source projects. A quick look at the many projects listed in those support services indicates that the Jetty project is not being an outlier with this policy. In fact we are simply recognising the reality of long term support that most other open source projects have long seen and we are moving towards to the norm.

[joakime]

Jetty 9.4 has simply become, overnight and arbitrarily, a version of Jetty that must no longer be used under the threat of receiving no further security fixes.

The announcement of Jetty 9.4 EOL occurred on May 2022.

• EOL (End of Life) for Jetty 9 - January 2025 #7958

(That issue was pinned on Jetty issue tracker from May 2022 thru to Sept 2025)

The sunsetting, end of community support, EOL status of Jetty 9.4 was also sent on jetty-announce.

• https://www.eclipse.org/lists/jetty-announce/msg00163.html - Nov 2021
• https://www.eclipse.org/lists/jetty-announce/msg00168.html - May 2022

If you tried to file an issue on Jetty, you would also see the End of Community Support text.

jetty.project/.github/ISSUE_TEMPLATE/issue-template.md

Line 11 in dae4aa8

<!--[Jetty 9.x is now at End of Community Support](https://github.com/jetty/jetty.project/issues/7958) -->

(Issue text was added July 2022)

From May 2022 there was no open source community support for Jetty 9.4 anymore.
No expectations of releases, no expectations of CVEs, etc...

In short, the announcements 3 years ago does not fit the "overnight" nor "arbitrarily" labels you are throwing out here.
This wasn't sprung suddenly, and was communicated to the community at large in several ways.

[olamy]

@openconcerto the Jetty team will be at the Paris JUG on the 9th December maybe come and discuss about this?