3 ms·

> six months is a ridiculous pace to package/distribute a new major version I agree, which is why we've done away with major releases altogether. There have b

by pron 7y ago

> six months is a ridiculous pace to package/distribute a new major version I agree, which is why we've done away with major releases altogether. There have been feature releases every six months with major new features for over ten years now. All that's changed is that we've changed how they're named and removed the major releases. And if you've found it acceptable that the 8u20 feature releases stopped getting patches after six months, and upgraded to 8u40, it shouldn't matter much that we now give those versions an integer number. Not only do you not need to package a new major release every six months, but you don't need to package a new major release ever again! Your assumption that it's significantly harder to switch from 11.0.2 to 12 than it is to switch from 11.0.2 to 11.0.3 does not seem to be based on any data we've seen. Most organizations that can do the latter can do the former. Not only the result will be cheaper and easier overall, but you'd get to enjoy all the performance and serviceability features even if you don't want to use new language/library features. > Almost every other organization I've talked with is sticking to the LTS, with plans to jump from JDK 11 to JDK 17 when it comes around. That will change soon (it already is changing), as more people understand the new model and the change to the version names. However, even if you are certain that your choice of LTS is justified (and I must say that it doesn't seem like you fully understand the new model yet -- which is OK, many don't, and it will take time), you must test your code on the current JDK. Updating from 11 to 17 without doing that is taking a huge risk. You will see features disappear without deprecation warnings.

cesarb 7y ago
> Updating from 11 to 17 without doing that is taking a huge risk. You will see features disappear without deprecation warnings. If upgrading from one stable release to the next stable release removes features without a deprecation period, something's wrong with the release model.
- pron 7y ago
  No, stable releases do get deprecation warnings, but that's not what LTS is. LTS is a service that's added by vendors to arbitrarily chosen versions. In fact, there is no such thing as "an LTS release." You can start offering LTS for JDK 12 tomorrow, making it -- retroactively -- LTS. The OpenJDK development process doesn't take those services into account; in fact the development process has no notion of LTS at all (e.g. can you see LTS mentioned here https://openjdk.java.net/projects/jdk/11/ https://openjdk.java.net/projects/jdk/11/ ?). All feature versions are equal in their stability. LTS is something a release can have, not something it is. All versions between 11 and 17 are stable, and none of them -- including 11 and 17 -- are major releases. Those are gone. LTS is a service designed for organizations with special constraints, and should be no means be your default choice. Moreover, there are multiple LTS services and they differ quite widely in what they offer and who they're aimed at. Put simply, LTS does not mean what it means in other projects. Do not choose it until you've learned exactly what the new model means and what LTS means.
- Scarbutt 7y ago
  Versions 12 to 16 are/will be stable releases.
sangnoir 7y ago
> However, even if you are certain that your choice of LTS is justified (and I must say that it doesn't seem like you fully understand the new model yet -- which is OK, many don't, and it will take time), you must test your code on the current JDK. I think this the italicized portion is the disconnect between what Oracle wants Java users to do, and what they'd rather not do. I know the pain of wanting your users to always be on the latest and greatest version, but in my experience, medium-to-large corporates are extremely risk averse and would rather invest time upfront to do testing/qualifying software releases before deploying, then keep that deployment running for as long as possible with the assurance that the configuration is stable (or at least has known & documented failure modes). They understand the new model just fine - they just don't want it. Mostly because it introduces a lot of risk and/or requires continuous qualification, which is not only expensive but completely changes the way they operate.
- pron 7y ago
  I understand that, I'm just saying that if your risk calculation concludes that LTS is less risky by default, then it's based on false assumptions, based on misunderstanding. The new feature releases are not major releases. If companies were fine upgrading to feature ("limited update") releases while there were still major releases around, I don't see why they would be more risky now that major releases are gone. I think that people can perceive them to be more risky because they confuse the change to the way those releases are named with the old major releases. For some companies, getting an LTS service is less risky, but not because of some intrinsic quality of LTS but because of their particular internal processes. For a great many companies, sticking to the default, gradual update process is the cheapest, least risky option. Moreover, there are also special risks to LTS programs, particularly the free ones. A much smaller number of people work on them (about 1/50 of the total number of people working on OpenJDK), and they completely rely on backports from the mainline. So, for example, once the CMS collector is removed from the mainline, it becomes unsupported in some LTS programs (certainly the free ones) because there are no longer fixes to backport, and they don't have the resources to fix bugs without backports. Finally, you can't talk about risk and treat LTS as a single thing, as the different LTS programs vary greatly in their risk vs. conservativeness. The Oracle LTS service contains almost only true patches: bug and security fixes, like the first two patches for each feature release. Red Hat's LTS/OpenJDK Updates and Azul's Zulu backport huge new features in their "patches." Amazon considers (or considered) taking the current VM and backporting it as a whole to an old JDK version in a "patch."

by pron 7y ago

cesarb 7y ago

> Updating from 11 to 17 without doing that is taking a huge risk. You will see features disappear without deprecation warnings. If upgrading from one stable release to the next stable release removes features without a deprecation period, something's wrong with the release model.

pron 7y ago
No, stable releases do get deprecation warnings, but that's not what LTS is. LTS is a service that's added by vendors to arbitrarily chosen versions. In fact, there is no such thing as "an LTS release." You can start offering LTS for JDK 12 tomorrow, making it -- retroactively -- LTS. The OpenJDK development process doesn't take those services into account; in fact the development process has no notion of LTS at all (e.g. can you see LTS mentioned here https://openjdk.java.net/projects/jdk/11/ https://openjdk.java.net/projects/jdk/11/ ?). All feature versions are equal in their stability. LTS is something a release can have, not something it is. All versions between 11 and 17 are stable, and none of them -- including 11 and 17 -- are major releases. Those are gone. LTS is a service designed for organizations with special constraints, and should be no means be your default choice. Moreover, there are multiple LTS services and they differ quite widely in what they offer and who they're aimed at. Put simply, LTS does not mean what it means in other projects. Do not choose it until you've learned exactly what the new model means and what LTS means.
Scarbutt 7y ago
Versions 12 to 16 are/will be stable releases.

sangnoir 7y ago

> However, even if you are certain that your choice of LTS is justified (and I must say that it doesn't seem like you fully understand the new model yet -- which is OK, many don't, and it will take time), you must test your code on the current JDK. I think this the italicized portion is the disconnect between what Oracle wants Java users to do, and what they'd rather not do. I know the pain of wanting your users to always be on the latest and greatest version, but in my experience, medium-to-large corporates are extremely risk averse and would rather invest time upfront to do testing/qualifying software releases before deploying, then keep that deployment running for as long as possible with the assurance that the configuration is stable (or at least has known & documented failure modes). They understand the new model just fine - they just don't want it. Mostly because it introduces a lot of risk and/or requires continuous qualification, which is not only expensive but completely changes the way they operate.

pron 7y ago
I understand that, I'm just saying that if your risk calculation concludes that LTS is less risky by default, then it's based on false assumptions, based on misunderstanding. The new feature releases are not major releases. If companies were fine upgrading to feature ("limited update") releases while there were still major releases around, I don't see why they would be more risky now that major releases are gone. I think that people can perceive them to be more risky because they confuse the change to the way those releases are named with the old major releases. For some companies, getting an LTS service is less risky, but not because of some intrinsic quality of LTS but because of their particular internal processes. For a great many companies, sticking to the default, gradual update process is the cheapest, least risky option. Moreover, there are also special risks to LTS programs, particularly the free ones. A much smaller number of people work on them (about 1/50 of the total number of people working on OpenJDK), and they completely rely on backports from the mainline. So, for example, once the CMS collector is removed from the mainline, it becomes unsupported in some LTS programs (certainly the free ones) because there are no longer fixes to backport, and they don't have the resources to fix bugs without backports. Finally, you can't talk about risk and treat LTS as a single thing, as the different LTS programs vary greatly in their risk vs. conservativeness. The Oracle LTS service contains almost only true patches: bug and security fixes, like the first two patches for each feature release. Red Hat's LTS/OpenJDK Updates and Azul's Zulu backport huge new features in their "patches." Amazon considers (or considered) taking the current VM and backporting it as a whole to an old JDK version in a "patch."