4 ms·

Conversely, some applications would like a leaky abstraction they have some control over. Some caching will likely remain beneficial to link to a carrier thread

Conversely, some applications would like a leaky abstraction they have some control over. Some caching will likely remain beneficial to link to a carrier thread. As a member of the Cassandra community I’m super excited to get my hands on virtual threads come the next LTS (and Cassandra’s upgrade cycle), as it will permit us to solve many outstanding problems much more cheaply. I hope by then we’ll also have facilities for controlling the scheduling of virtual threads on carrier threads. I would rather not wait another LTS cycle to be able to make proper use of them.

pron 4y ago
LTS is a designation by our sales organisation for arbitrarily chosen versions so they can offer a support service for legacy codebases -- i.e. people willing to pay for the privilege of not getting new features [1]. Why anyone would wait for something intended for the sole purpose of not adding new features to get a new feature --and so enjoying the very worst of both worlds -- is beyond me. The development organisation has no consideration of support offerings. All releases are equal, and the assumption is that those who want new features obviously do not want LTS and vice-versa. Anyway, the mention of the perennially misunderstood Java LTS is a pet peeve of mine, so I'm sorry if this comment was overly aggressive. [1]: There are many legacy applications that aren't actively developed. They have no use for new features, and new features sometimes requires changing configurations -- a hassle they don't have the people to do. So LTS is a subscription service that allows them to get releases without new features so they can keep running legacy apps without much maintenance. It's a great service, but obviously the opposite of what actively maintained codebases want; for them we have the regular upgrade model.
- Twisol 4y ago
  > Anyway, the mention of the perennially misunderstood Java LTS is a pet peeve of mine, so I'm sorry if this comment was overly aggressive. I, for one, appreciate the repeat. I usually have to go hunting for one of your much older Reddit comments when this topic comes up at work.
- btbuilder 4y ago
  The good work to slim down and better compartmentalize the JDK has historically created enough backward incompatibility risks for me that I prefer staying on the same version longer than 6 months. If I want security updates for the version I’m on LTS is the best (only?) way.
  - pron 4y ago
    I think Java has never had better backward compatibility than now. The difficulties migrating to 9 were 1. due to 9 being the last major release ever, and 2. libraries that hacked JDK 8's internals and were not portable, so they broke in a big release. The overall upgrade costs now are also lower than ever before, and we know that because some companies do understand that using the current version is easier and cheaper than an old one. Having said that, if you want to stay on an old version for a long time, then yes, use one with LTS, but then you might as well upgrade very slowly (not every two years) because upgrades will be less pleasant.
    - btbuilder 4y ago
      I agree, Java compatibility is much better now. For Java 9 there were also runtime breaking changes like removal of javax classes and removal of javaFX. >6 months is not really a long time for enterprise software.
      - pron 4y ago
        But Java has always had semi-annual feature releases, and there wasn't even LTS -- people had to upgrade to a new feature release ever six months. It's just that we dropped major releases altogether and then gave the feature releases new version numbers, and that confused many people (who might not have even been aware that some of the minor releases in the past were actually quite significant feature releases). In other words, people upgraded to new feature releases every six months in the Java 7 and 8 era, too; now with major releases gone it's even easier, so it doesn't make sense that projects that were fine with such upgrades in the past all of a sudden need the new LTS model when things are even easier than before.
- _benedict 4y ago
  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.
  - pron 4y ago
    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.
    - _benedict 4y ago
      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.

pron 4y ago

LTS is a designation by our sales organisation for arbitrarily chosen versions so they can offer a support service for legacy codebases -- i.e. people willing to pay for the privilege of not getting new features [1]. Why anyone would wait for something intended for the sole purpose of not adding new features to get a new feature --and so enjoying the very worst of both worlds -- is beyond me. The development organisation has no consideration of support offerings. All releases are equal, and the assumption is that those who want new features obviously do not want LTS and vice-versa. Anyway, the mention of the perennially misunderstood Java LTS is a pet peeve of mine, so I'm sorry if this comment was overly aggressive. [1]: There are many legacy applications that aren't actively developed. They have no use for new features, and new features sometimes requires changing configurations -- a hassle they don't have the people to do. So LTS is a subscription service that allows them to get releases without new features so they can keep running legacy apps without much maintenance. It's a great service, but obviously the opposite of what actively maintained codebases want; for them we have the regular upgrade model.

Twisol 4y ago
> Anyway, the mention of the perennially misunderstood Java LTS is a pet peeve of mine, so I'm sorry if this comment was overly aggressive. I, for one, appreciate the repeat. I usually have to go hunting for one of your much older Reddit comments when this topic comes up at work.
btbuilder 4y ago
The good work to slim down and better compartmentalize the JDK has historically created enough backward incompatibility risks for me that I prefer staying on the same version longer than 6 months. If I want security updates for the version I’m on LTS is the best (only?) way.
- pron 4y ago
  I think Java has never had better backward compatibility than now. The difficulties migrating to 9 were 1. due to 9 being the last major release ever, and 2. libraries that hacked JDK 8's internals and were not portable, so they broke in a big release. The overall upgrade costs now are also lower than ever before, and we know that because some companies do understand that using the current version is easier and cheaper than an old one. Having said that, if you want to stay on an old version for a long time, then yes, use one with LTS, but then you might as well upgrade very slowly (not every two years) because upgrades will be less pleasant.
  - btbuilder 4y ago
    I agree, Java compatibility is much better now. For Java 9 there were also runtime breaking changes like removal of javax classes and removal of javaFX. >6 months is not really a long time for enterprise software.
    - pron 4y ago
      But Java has always had semi-annual feature releases, and there wasn't even LTS -- people had to upgrade to a new feature release ever six months. It's just that we dropped major releases altogether and then gave the feature releases new version numbers, and that confused many people (who might not have even been aware that some of the minor releases in the past were actually quite significant feature releases). In other words, people upgraded to new feature releases every six months in the Java 7 and 8 era, too; now with major releases gone it's even easier, so it doesn't make sense that projects that were fine with such upgrades in the past all of a sudden need the new LTS model when things are even easier than before.
_benedict 4y ago
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.
- pron 4y ago
  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.
  - _benedict 4y ago
    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.