revised snapshot of the state of conversation here:
*[New LTS JDK Adoption]*
• Trunk supports 1 JDK at a time
• After a branch is cut for a release, we push to get trunk to support latest
LTS JDK version available at that time
• Trunk targets the language level of that JDK
• CI on trunk is th
.
> For the rare edge case where we have to stop supporting something entirely
>> because it's incompatible with a JDK release (has this happened more than
>> the 1 time?) - I think a reasonable fallback is to just not backport new
>> JDK support and consider carrying forward the older JDK su
.
>
> For the rare edge case where we have to stop supporting something entirely
> because it's incompatible with a JDK release (has this happened more than
> the 1 time?) - I think a reasonable fallback is to just not backport new
> JDK support and consider carrying forward the older JDK suppo
Great context - thanks for that insight.
Operators running the older supported versions of C* will retain the *option*
to run the older JDK, however if they want to upgrade their JDK version and C*
version *separately* under the above paradigm, they'd need to rev their JDK
separately on their c
Benedict, I am not sure what do you mean by optional feature. FWIW we
cannot compile cassandra-4.1 until we removed the feature in cassandra-5.0.
I, as a user would be very disappointed a feature to be removed in a patch
release.
Yes, replacing nashorn was the unpleasant part. I did not raise the
“I'm curious what this raises for you. “
A few points that come to mind:
- every time we switch/add JDKs we also need to do a bunch of changes in CI
systems, ccm, etc, not only C* - so more work to call out. Also, if we make
older versions support newer JDK, I guess we need to ensure drivers, etc
Yes the issue of Nashorn did spring to mind, but as I recall this was an optional feature. I don’t remember how hard it would have been to simply declare the feature unavailable if you use the newer JDK, but my vague recollection is the hard part was primarily finding a suitable replacement.We may
Lessons learned from advancing JDK support on trunk *should* translate into
older branches making that effort much smaller; Ekaterina you have a lot of
experience here so I'm curious what this raises for you. I like the
productivity implications of us being able to adopt new language features
f
Perhaps we should consider back porting support for newer Java LTS releases to
older C* versions, and suggesting users upgrade JDK first. This way we can have
trunk always on the latest LTS, advancing language feature support more
quickly.
That is, we would have something like
N-2: JDK, JDK-
> You don’t have to run every suite on every commit since as folks have pointed
> out for the most part the JVM isn’t culprit. Need to run it enough times to
> catch when it is for some assumption of “enough”.
So riffing on this. We could move to something like:
• For each given supported C* br
.
> So yeah. I think we'll need to figure out how much coverage is reasonable
>> to call something "tested". I don't think it's sustainable for us to have,
>> at any given time, 3 branches we test across 3 JDK's each with all our
>> in-jvm test suites is it?
>>
>
Correct.
For non-upgrade test
When I worked on Riak we had a much more complex matrix due to supporting
even more backwards compatibility. It’s not unfeasible. You don’t have to
run every suite on every commit since as folks have pointed out for the
most part the JVM isn’t culprit. Need to run it enough times to catch when
it i
> The problem with (2) being only "overlapping JDK version support on
> consecutive releases" instead of an overlapping JDK over all `N-2` releases
> is that we say we support upgrade paths that we never test (w/
> jvm-dtest-upgrade). Here, I would rather add a third LTS JDK to a release to
>
On Tue, May 20, 2025 at 08:12 Josh McKenzie 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-ro
Another thing to consider is the usage of JDK internals. The JDK developers
do not promise backward compatibility for internals. We still have things
like jamm that need updates, and not only jamm. Sometimes they can fail us
silently despite fully green CI.
Performance is a good point - we don’t e
There are performance differences between JVMs. I agree that bug testing of JVM versions for clients is not very important, but isolating JVM characteristic changes from database characteristic changes is important, for me at least.On 20 May 2025, at 17:47, Jon Haddad wrote:If you're upgrading an
.
> If it came down to either:
>
>1. Support latest 2 LTS JDK on any given C* release, no overlap.
>Operators deal with it.
>2. Require 1 overlapping JDK version support on consecutive releases.
>Users may have to wait a year for new JDK features
>
>
My opinions…
- we sho
> This gets stated on perhaps an annual basis, so perhaps we should start
> having these conversations on wiki to avoid the repetition.
I didn't state this in my original email: my goal is to come to a consensus and
codify it in the wiki going forward.
> * or do the two version thing and not bot
If you're upgrading an environment without doing any additional testing -
sure, it can be helpful to isolate the issue.
However, outside of this scenario, where you actually test your upgrade
process and vet the functionality, I don't see it as a big gain - certainly
not enough of one to hold the
On Tue, May 20, 2025 at 10:59 AM Jon Haddad wrote:
> > There is also that recommendation that I keep on hearing - don’t do C*
> > major upgrade and JDK upgrade simultaneously. I believe that was one of the
> > reasons for overlap too
>
> There's no practical reason for this today. Maybe in the
While I understand *some* users care, we shouldn't take the preferences of
a very small minority of users as project policy. I've worked with
hundreds of teams, and I can't recall a single one caring about doing A/B
testing in JVM versions.
> There is also that recommendation that I keep on heari
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.
There is also that recommendation that I keep on hearing - don’t do C*
major upgrade and JDK upgrade simultaneously. I believe that was one of the
reasons for overlap too
On Tue, 20 May 2025 at 11:36, Jon Haddad wrote:
> There’s no “leaving users in the lurch” by requiring JDK upgrades.
>
> If u
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
24 matches
Mail list logo
