Re: [DISCUSS] How we handle JDK support

[Benedict]

In-jvm dtests need to execute an upgrade path on a single jvm, but this is close to always possible on the latest jvm. We haven’t hit any issues that I know of in this respect during any version change, so I don’t think this is a real concern. Some users do care about overlapping JVM compatibility. Containers may be exceptionally common but it is far from 100% coverage, and some operators (myself included) prefer to decouple the effects of two different version upgrades so as to decipher what change causes what effect. This gets stated on perhaps an annual basis, so perhaps we should start having these conversations on wiki to avoid the repetition. On 20 May 2025, at 16:37, Jon Haddad <j...@rustyrazorblade.com> wrote:  There’s no “leaving users in the lurch” by requiring JDK upgrades.  If users are using containers (pretty much everyone i talk to) then the JDK is included, versions don’t matter.  If not, every modern Linux distro supports multiple installed JDKS. Again, not a problem.  So far the only convincing argument I’ve heard is that we need overlapping versions because of in-JVM dtests. Which is a shame, but sounds unavoidable without a massive change that I’m sure nobody is interested in.  Let’s not pretend like we’re doing this for the users though, they aren’t getting any benefit from it.   Jon On Tue, May 20, 2025 at 8:12 AM Josh McKenzie <jmcken...@apache.org> wrote: This came up in the release versioning thread and we punted to its own thread. Topic: How do we want to handle JDK version support in C* releases? Oracle LTS policy here: https://www.oracle.com/java/technologies/java-se-support-roadmap.html My first rough thoughts: Any given C* release will only support 2 JDK / JRE at any given time We only change JDK support on MAJOR releases (i.e. not patch) When we add support for a new JDK, we drop support for the older in that release Every consecutive release must share support for a runtime JDK version with one version older (this allows for live upgrades, CI, etc). So if we take a long time releasing C* and multiple JDK's rev, we don't jump from [11,17] supported to [21,23] and leave users in a lurch on the straddle We confirm C* builds on both supported JDK's We run all test suites against all supported JDK's for a release (yet more incentive to clean up slow tests..) Language level support will be constrained to oldest JDK supported We make an effort to support the latest LTS JDK on any given C* release (i.e. 21 now, 25 next major when it goes LTS Sep of this year) The major downside I can think of with the above is operators will need to verify a new JDK maximally once every 2-3 years as older LTS support is dropped. What am I not thinking of? What are other downsides with the above proposal?