Well, it is not just Oracle that has adopted the LTS designations. AdoptOpenJDK and others are also selecting the same LTS versions to provide longer term support promises for, including security and other improvements.
A major project like Cassandra that is non-trivial to upgrade (but is desirable to upgrade, and to have security fixes for) simply cannot hop Java version every year and impose that additional burden on our users, and nor can we pick a Java version that is not guaranteed security updates past some near term horizon. So we pick versions that people are expected to have available them for the lifetime of that release in their environment.
Honestly I’m not sure what you’re upset about, I am a bit surprised at the vehemence of your response to that element of my comment. Also a little disappointed you didn’t engage with the rest of my comment; I hope that doesn’t mean I also end up disappointed with the near future of virtual threads.
A major project like Cassandra will find that it is easier to use the current version (before LTS existed, people had to upgrade to the six monthly feature releases, but because they didn't get a new version number people didn't care as much). If it does cause trouble, let us know, because LTS really isn't intended for actively maintained projects that want new features and isn't the recommended path for them. Just note that the free upgrade services called LTS are not quite the same; they just include backports from mainline and don't support the whole JDK.
Anyway, I'm sorry about my tone. I know that the change in the version numbering scheme confused people to pick the wrong upgrade path for themselves, and it's our fault for miscommunicating. But I don't know when features will land, or when those who want new features with an LTS service will be able to use them. But I can say that our process assumes that those who want long-term support are trying to avoid new features and are happier when a big feature misses the next release with LTS, so while missing one release normally means a mere 6 month delay, those who wait for LTS for actively developed codebases (even though it's due to a misunderstanding) might have to wait a further couple of years.
Well, whatever each of our perceptions about the utility of selecting an LTS, there are realities we all occupy - and LTS releases are a part of Cassandra's reality for the time being. Perhaps that will change in future, but I do not anticipate it very soon.
But, I will be pushing for the adoption of virtual threads once they become more useful for the community (which I think the previously mentioned improvements predicate). So, whatever the realities JEP425 operates within, I do hope these improvements land by Java 21, so that my job is made easier.
Either way, really excited about the work, whenever it transpires that we can use it. Thanks for your efforts delivering it so far.
A major project like Cassandra that is non-trivial to upgrade (but is desirable to upgrade, and to have security fixes for) simply cannot hop Java version every year and impose that additional burden on our users, and nor can we pick a Java version that is not guaranteed security updates past some near term horizon. So we pick versions that people are expected to have available them for the lifetime of that release in their environment.
Honestly I’m not sure what you’re upset about, I am a bit surprised at the vehemence of your response to that element of my comment. Also a little disappointed you didn’t engage with the rest of my comment; I hope that doesn’t mean I also end up disappointed with the near future of virtual threads.