We are working actively on Jetty 12 at the moment. That's where the majority of effort currently is.
Jetty 10 and Jetty 11 have the next level of effort (we recently added QUIC + HTTP/3 support there, due out soon), these see the most frequent releases currently.
Jetty 9 is in maintenance mode, and effort there is minimal, and our recent trend of releases is not monthly here, but more quarterly.
As for how the death of Jetty 9 will happen, that depends firstly on Java 8 public support, then how far the industry has moved beyond the capabilities of Jetty 9.
One of the most important aspects of Java 8 public support is if we cannot access the latest OpenJDK 8 release due them being behind contractual support requirements, then Jetty 9 will die on the vine, as we cannot support Java 8 anymore.
If we look at past JVM/JDK release behaviors as an example, once the JVM support mode for "Premier Support" ends, and "Extended Support" begins, that's when JVM/JDK releases become private and non-public (
for Java 8, that is scheduled for March 2022).
Java 8 has seen some dramatic changes at the JVM level over the past few years as a result of
industry wide Crypto changes, these are pressures that require you to update your version of Java or just outright fail to talk to encrypted endpoints on the public internet.
New Java major version releases roll in these dramatic changes as part of their process.
This is one reason Jetty 9.4.44 doesn't work reliably on older Java 8 releases, nor do newer Java 8 releases work reliably on older Jetty 9 releases. (We had to make changes in Jetty to support changes in the Java 8 JVM level for crypto/networking).
Basically, if you are using SSL/TLS, be it from a server point of view, or even a client point of view, and are using the public internet, then you have to keep your Java versions up to date at a minimum. (You are taking note of the JVM expiration dates in their release notes and updating your JVM before they expire, right?)
We've even seen changes introduced because of Java 9+ (eg: JPMS metadata, Multi-Release jar files, etc) impact the ability of Jetty 9 to run on Java 8 runtimes!
Who knows what new concept or technology in Java 18/19/20 will break your Jetty 9 on Java 8 runtime due to incompatibilities introduced at the artifact/jar/dependency level.
We've even seen changes introduced by Browser vendors break old versions of Jetty.
Example: when Chrome started enforcing Cookie "SameSite" attributes (rejecting the cookie if it wasn't present).
Then there's the pressures from the java software industry to contend with as well.
Spring 6 has embraced the "Jakarta Big Bang" and is moving away from `javax.servlet` to `jakarta.servlet` (and related tech), along with bumping the minimal JVM support on Spring to Java 17.
Most projects that have even a slight connection with spring are also updating now to the same minimums.
In short, if you are using Java 8 and Jetty 9 entirely within your own infrastructure, and never have it exposed to the public internet (in or out), then you are fine.
But if you have to support the public internet, you should start the process to upgrade either your JVM (to Java 17) or Jetty soon.
The longer you wait, the more intense and stressful the update will be for you when something out of your control forces you to upgrade.
