We agreed on not dropping a JDK if it'd kill a feature (or at least called out the shape of this challenge): https://cwiki.apache.org/confluence/display/CASSANDRA/JDK+Version+Support+Policy
> In the very rare case a feature would have to be removed due to JDK change > (think UDF's scripting engine)... So we at least spoke to the implications on *part* of the intersection of JDK support and features. Good points Ekaterina and Scott - this would throw a wrinkle in my "backporting runtime support to older branches should be easy" claim. Barring those kind of exceptions I don't think it'll be a huge *technical* hurdle going forward. I'm not sure how we want to tackle this and if there'd be a path for conditional run of newer JDK w/Nashorn disabled at runtime that'd work; don't know enough about that impl to know if it's even a sane line of questioning. :) > - 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 I reached out to Jonathan Ellis about this; he's receptive to us merging the jamm codebase into the C* repo which would make it far simpler to modify, test, and maintain. I don't love the idea of having to carry jamm support into the future but on reflection I think that primarily stems from the hurdle of maintaining and validating it in a separate repo. There aren't really any obvious license-compatible alternatives so at the very least, getting it to low friction to validate and modify jamm should help. On Tue, Nov 11, 2025, at 11:03 AM, C. Scott Andreas wrote: > 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 >>>> • >>> > >
