The most pressing motivation for folks to get off JDK11 is that many organizations consider it
end-of-life. It was released 7 years ago and Oracle Premier support ended two years ago, so it's in
its final "extended support" lifecycle which runs through 2032 at what I'm sure is
substantial expense. Agree with Ekaterina's concerns about Nashorn removal in JDK15+ and the impact
to API surface. Good motivation to stay current in all respects – for us to continue advancing
support for new JDK LTS releases; and for users to upgrade to current major versions of the database.
On Nov 11, 2025, at 7:48 AM, Ekaterina Dimitrova <[email protected]> wrote: “fwiw - I think
backporting the ability to run on JDK21 (or any newer JDK tbh) should be pretty simple and a
favorable cost/benefit. Just want to explore if it's just the GC in the new JDK or something else at
runtime people are looking for.” Some caveats which are not about complexity but which need to be
considered: - we removed scripted UDFs to move forward and are not going to remove them in 4.1
(CASSANDRA-18252) - jamm update will be needed, to the version we have in 5.0 or we may need new
release of jamm for versions post JDK 17. It may lead to flushing change of behavior etc in a patch
release On Tue, 11 Nov 2025 at 10:29, Josh McKenzie < [email protected] > wrote: [Must have]
Minimum JDK21 support on 4.1 and higher Is this purely due to genZGC? While it's playing very nicely
so far, I would expect the gap between tuned G1 and genZGC to be less than tuned CMS and genZGC. @Jon
Haddad - got any insight on the above (CMS vs. G1 vs. shenandoah vs. genZGC)? fwiw - I think
backporting the ability to run on JDK21 (or any newer JDK tbh) should be pretty simple and a
favorable cost/benefit. Just want to explore if it's just the GC in the new JDK or something else at
runtime people are looking for. On Fri, Oct 31, 2025, at 2:14 PM, Jaydeep Chovatia wrote: [Must have]
Minimum JDK21 support on 4.1 and higher
