15 ms·

Man, I disagree. For large enterprises, six months is a ridiculous pace to package/distribute a new major version. The fact that it is just enhancements does

by heelix 7y ago

Man, I disagree. For large enterprises, six months is a ridiculous pace to package/distribute a new major version. The fact that it is just enhancements does not matter. It may seem simple, but most implementations have that integer as part of the deployment path. The aggressive deprecation/removal in the 'major' six month cycle has been rough. If this is my local workstation, no worries. It creates chaos on work systems, however. (Did a decade+ at Oracle, and now at a shop three times its size. You should understand inflexibility and moving at the speed of business. :P ) There still are quarterly patches to the LTS releases (7u241, 8u231, 11.0.5), with the next batch due the second week of January for all the LTS versions - 7/8/11 on the Oracle side, 8/11 on the Adopt OpenJDK, and other OpenJDK implementations possibly supporting all three. 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. (and hearing the woes of all the folks still trying to get past JDK 8)

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.

by heelix 7y ago

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.