4 ms·

Seriously? I'm a developer and if I would be left to my own devices I would upgrade to the newest beta software where possible and run Java 21 EA with enable-p

by krzyk 3y ago

Seriously? I'm a developer and if I would be left to my own devices I would upgrade to the newest beta software where possible and run Java 21 EA with enable-preview. The only stopper is lazy people and infosec.

hdaz0017 3y ago
they call it bleeeeeding-edge for a reason ;)
solatic 3y ago
Are you a developer for a Fortune 100? The only thing that matters in large + long-lived engineering organizations is organizational buy-in, and that's only remotely possible with LTS, because anything with shorter upgrade cycles takes too much time to get too many other people to buy in before a new version is released (and the old version is no longer supported). There's a reason why you see a ton of stuff like VBA in the military, and it's not because VBA is usually the best tool for the job by any technical metric. It's because the people who chose it didn't need to align 100+ other stakeholders in order to pick a different tool; they were able to start implementing what they needed immediately.
- signal11 3y ago
  > The only thing that matters in large + long-lived engineering organizations is organizational buy-in, and that's only remotely possible with LTS This is an archaic view and certainly not true for all Fortune 100 teams. Plenty of them have digital platforms that bring in lots of money, and staying with legacy tech isn’t going to be good for business when faced with new, nimble challengers. Learning from the wider industry, FAANG included, is the smart thing to do. > LTS The key here is to save $$$ and stay secure. LTS is just deferred cost and pain. For teams with good tests and CI for instance — if they’ve migrated to Java 11, upgrading the JVM is relatively easy after that. Staying on LTS releases for ages is costly as you’re just deferring cost, as even Oracle JDK contributors have pointed out. Ultimately it’s a cost/benefit equation, but often it’s economically sensible to bite the bullet and upgrade from Java 8 -> 11, and then upgrade more regularly. Incidentally, Oracle’s recommendation is to perform Java LTS upgrades every 3 years. Sure you can defer further, but it’ll cost you. Oracle support ain’t free. But most well-run teams with tests and CI can move every 12-24 months. [1] [1] https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_is_not_tck_compliant_at_the_moment/es3bjar/ https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i... , https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_is_not_tck_compliant_at_the_moment/es3cn6p/ https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i...
  - krzyk 3y ago
    > Oracle’s recommendation is to perform Java LTS upgrades every 3 years. I think now it is 2 years, because that's the span between LTS releases from Oracle.
    - signal11 3y ago
      I believe the 3 year period was recommended keeping the 2 year LTS release policy in mind, the idea was that teams don’t have to upgrade to the new LTS immediately, they can spend a year in testing before switching their production JVM.
  - solatic 3y ago
    > well-run teams with tests and CI Well-run by what criteria? Pournelle's Iron Law of Bureaucracy points out that any large-enough organization (certainly F100's are large enough to count) will be run by people who take care of the organization, rather than people who pursue the organization's goals. Most such teams are "well run" if they provide people with stability. No surprises, no forced upgrades, no rocking the boat, just an environment that let's people clock in and clock out with a feeling that they work in a supportive environment that appreciates them. Too many companies interpret CI as something that prevents them from delivering their work, or something that forces them to stop what they're doing to fix the main branch. In these companies, throwing something over the wall to someone else is a feature, not a bug. And if the person on the other end of that wall's only request is to still keep shipping Java 8? Well fine, so be it.

by krzyk 3y ago

hdaz0017 3y ago

they call it bleeeeeding-edge for a reason ;)

solatic 3y ago

Are you a developer for a Fortune 100? The only thing that matters in large + long-lived engineering organizations is organizational buy-in, and that's only remotely possible with LTS, because anything with shorter upgrade cycles takes too much time to get too many other people to buy in before a new version is released (and the old version is no longer supported). There's a reason why you see a ton of stuff like VBA in the military, and it's not because VBA is usually the best tool for the job by any technical metric. It's because the people who chose it didn't need to align 100+ other stakeholders in order to pick a different tool; they were able to start implementing what they needed immediately.

signal11 3y ago
> The only thing that matters in large + long-lived engineering organizations is organizational buy-in, and that's only remotely possible with LTS This is an archaic view and certainly not true for all Fortune 100 teams. Plenty of them have digital platforms that bring in lots of money, and staying with legacy tech isn’t going to be good for business when faced with new, nimble challengers. Learning from the wider industry, FAANG included, is the smart thing to do. > LTS The key here is to save $$$ and stay secure. LTS is just deferred cost and pain. For teams with good tests and CI for instance — if they’ve migrated to Java 11, upgrading the JVM is relatively easy after that. Staying on LTS releases for ages is costly as you’re just deferring cost, as even Oracle JDK contributors have pointed out. Ultimately it’s a cost/benefit equation, but often it’s economically sensible to bite the bullet and upgrade from Java 8 -> 11, and then upgrade more regularly. Incidentally, Oracle’s recommendation is to perform Java LTS upgrades every 3 years. Sure you can defer further, but it’ll cost you. Oracle support ain’t free. But most well-run teams with tests and CI can move every 12-24 months. [1] [1] https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_is_not_tck_compliant_at_the_moment/es3bjar/ https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i... , https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_is_not_tck_compliant_at_the_moment/es3cn6p/ https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i...
- krzyk 3y ago
  > Oracle’s recommendation is to perform Java LTS upgrades every 3 years. I think now it is 2 years, because that's the span between LTS releases from Oracle.
  - signal11 3y ago
    I believe the 3 year period was recommended keeping the 2 year LTS release policy in mind, the idea was that teams don’t have to upgrade to the new LTS immediately, they can spend a year in testing before switching their production JVM.
- solatic 3y ago
  > well-run teams with tests and CI Well-run by what criteria? Pournelle's Iron Law of Bureaucracy points out that any large-enough organization (certainly F100's are large enough to count) will be run by people who take care of the organization, rather than people who pursue the organization's goals. Most such teams are "well run" if they provide people with stability. No surprises, no forced upgrades, no rocking the boat, just an environment that let's people clock in and clock out with a feeling that they work in a supportive environment that appreciates them. Too many companies interpret CI as something that prevents them from delivering their work, or something that forces them to stop what they're doing to fix the main branch. In these companies, throwing something over the wall to someone else is a feature, not a bug. And if the person on the other end of that wall's only request is to still keep shipping Java 8? Well fine, so be it.