EoCS (End of Community Support) for Jetty 10 / Jetty 11 - January 2024

[jmcc0nn3ll]

The recent announcement of the release of Jetty 12 marks the beginning of the transition to Jetty's new primary development branch. One very exciting feature of Jetty 12 is its support for both javax and jakarta servlets, currently with the same environments available in Jetty 10 (EE8), Jetty 11 (EE9), and the latest EE10 environment. This also means that upcoming releases like EE11 can be added to Jetty 12 with, at most, a minor version bump.

In light of these Jetty 12 features, it is time to announce how support for these older releases will continue, specifically that 1 January 2024 will mark the official End of Community Support(EoCS) for Jetty 10 and Jetty 11.

With Jetty 12 providing ongoing support for both older and upcoming EE specifications, the community will benefit long-term with the migration onto Jetty 12. Fundamentally, users will benefit from the ability to maintain arbitrary EE deployments on a more featureful and performant HTTP server that improves independently.

We are compiling a Migration Guide to help the community.

Once EoCS is reached, users of these older versions will continue to see releases for security and critical issues until they go full End of Life (EOL), and the only ongoing support provided will be for Webtide customers. By way of example, Jetty 9 EoCS was announced in May of 2022, and there have been five customer-sponsored releases since that announcement.

The official EOL of Jetty 10 and Jetty 11 is January 1st 2025.

Action	Before Jan 1st, 2024	End of Community Support (Jan 1st, 2024)	End of Life (Jan 1st, 2025)
Community PRs reviewed and integrated	✔️	❌	❌
Webtide Customer PRs reviewed and integrated	✔️	✔️	❌
Community triggered releases	✔️	❌	❌
Webtide Customer triggered releases	✔️	✔️	❌
Security / Vulnerability triggered releases	✔️	✔️	❌

Thank you for your continued usage and support of Jetty; please take a moment to look at newer Jetty releases 12.0.x.

Jetty Version	Minimum JDK Version	Jakarta EE	Servlet Version	Namespace
12.0.x - env:ee8	17	EE8	4	javax.servlet.*
12.0.x - env:ee9	17	EE9	5	jakarta.servlet.*
12.0.x - env:ee10	17	EE10	6	jakarta.servlet.*

If you have questions or concerns, please don't hesitate to comment on this GitHub issue.

Updates to this message may occur, but this location is canonical for this announcement.

[joakime]

Are we sure that the Eclipse IDE folks are ok with making their minimum JDK version 17?

[jmcc0nn3ll]

Are we sure that the Eclipse IDE folks are ok with making their minimum JDK version 17?

I don't see that as a factor.

[sandeepnkulkarni]

@jmcc0nn3ll I think there are date mismatch within the table in original post. Just above the table EOL date is mentioned as 1 January 2025 but within table columns it is 1 January 2024. Can you please correct it just to avoid confusion?

[jmcc0nn3ll]

End of Community Service will likely be January 1 for Jetty 10 and 11, we don't know when we're going to be completely EOL those versions, that remains to be determined.

The statement of the paragraph that you're referring to I believe stated that it will not be completely EOL until January 1, 2025.

There's a difference in there.

Is that clearer?

(Edit) with Jetty 12 being able to handle the environments for both Jetty 10 and Jetty 11, there is little reason to keep them around for the general community.

[sandeepnkulkarni]

Just a thought from my side: Java 17 adoption is not very much still there (at least for Enterprise applications). People are still working on moving their old Java 8 applications to Java 11.

So ending community support for both Jetty 10 and Jetty 11 less than 2 years is bit too early IMO.

[jmcc0nn3ll]

That is interesting; we saw that a handful of years ago, but lately, we are seeing many more companies catching up with the release cadence of Java and at least updating to 17. We see a fair amount of Java 9 people sticking with Jetty 9.4.x when they are Java locked, but the lock-in on the Java version is less pronounced now, at least for versions between 9 and 17.

Still, interesting feedback, thank you! We will review the overall landscape at the start of the year and see what we want to do. Generally speaking, the focus for Jetty moving forward must be Jetty 12.

To be clear, Jetty 10 and Jetty 11 will continue to be supported for customers of Webtide, so the community will still see updates for the foreseeable future to both versions, basically while Webtide has customers using those versions. Security issues will be addressed as before, so the community can continue using them safely until we mark them EOL. Normal professional support will be available until they are marked EOL.

Simply put, the open-source project can only maintain so many versions of Jetty simultaneously, and four is too many. Jetty 12 has been the effort to trim down releases of Jetty due to the moving parts of Java and JakartaEE. For example, there should be a new EE version next year and the new environment will be available with Jetty 12.

[joakime]

@sandeepnkulkarni the latest eclipse poll shows Java 11 and Java 17 usage at over 90%, with the next highest at Java 21, with Java 8 in a distant 4th place.

Also note that many large online services (cloud, saas, etc) have publicly stated that Java 8 support ends on Jan 1, 2024.

[ijuma]

@joakime Do you have a link to the poll you mentioned?

[moritzfl]

On platforms such as Windows/Linux/macOS switching to newer Java versions can be done in a timely manner.

On z/OS systems, things look different. Java 17 was released last year in August for z/OS:
https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/james-tang1/2023/08/25/ibm-semeru-runtime-certified-edition-for-zos-versi?communityKey=7c1d7dc7-29aa-40f6-829c-934e4b522bf8

And if you support enterprise applications you need to make sure that your customers have time to move to the JDK before changing your software to drop support for Java 11. And we do not know IBMs release schedule and noone wants to switch on day one.

And then there is the timeframe "end of the year" where noone wants to risk any downtime of mission critical systems.
So yes - ending support for java 11 came too early for us too ...

[sbordet]

@moritzfl the open source community support is ended, but you have commercial support options available by contacting Webtide -- with a commercial support we would be able to help you.

Also, Java 17 for IBM on z/OS is available: https://www.ibm.com/docs/en/semeru-runtime-ce-z/17?topic=guide-whats-new

[dzhus]

Hello,

Just to clarify, does "End of Community Support (Jan 1st, 2024)" also mean "NO Security / Vulnerability triggered releases for Community"?
This point is a bit muddy to me from the table

– my initial hunch was that there'll still be security releases for community until EOL, although the comment from #12012 (comment) implies otherwise.

[joakime]

@dzhus also, as pointed out in the CVE-2024-6763 details, you'll see that the issue is ultimately a difference in parsing between the RFC3986 URI spec (that every network protocol that cares about URL/URI uses) and the WhatWG Living URL document (a non-spec that only browsers use).

The fix in Jetty 12 does not address this difference in parsing behavior, nor can it.

This behavioral difference in URL/URI is so vast that other projects, like spring, have 2 parsers, one that uses WhatWG rules, and another that uses RFC3986 rules.

• https://github.com/spring-projects/spring-framework/blob/main/spring-web/src/main/java/org/springframework/web/util/WhatWgUrlParser.java
• https://github.com/spring-projects/spring-framework/blob/main/spring-web/src/main/java/org/springframework/web/util/RfcUriParser.java

Since we are not a browser implementation, we only implement RFC3986 when it comes to parsing, and do not implement the WhatWG Living URL document rules.
In short, the original stated issue in CVE-2024-6763 cannot be mitigated by anyone using RFC3986 properly.
Jetty's solution was just to evaluate how authority is parsed, and how it applies to the various protocol specs, which in turn notes that the user-info portion is deprecated, which we implemented.

This kind of vulnerability needs to be addressed by a common URL/URI spec that both the browsers and the protocols can agree on.
Which, funny enough, has sort-of/kinda started on the ietf-http-wg mailing list.

• https://lists.w3.org/Archives/Public/ietf-http-wg/2024JulSep/0281.html

But any kind of wholesale change to URI/URL parsing from this kind of cooperation is years away from being a reality. (something Jetty will participate in, and will implement, when it starts to get defined in draft specs)

[joakime]

Deleted one of oddly doubled comments.