4 ms·

> 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 a

> 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.

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.