3 ms·

> If nothing else, they should be placated by the fact that upgrades are significantly worse in every other ecosystem. A lot of ecosystems care about their use

> If nothing else, they should be placated by the fact that upgrades are significantly worse in every other ecosystem. A lot of ecosystems care about their users and care about compatibility. Java is a toxic relationship at this point.

pron 3y ago
I think that Java's record on compatibility is unmatched, and users are extremely happy with all the enhancements we've been delivering, which why Java's popularity remains sky-high. But no product can satisfy everyone forever, and if you're unhappy, we'd like to try and address the issues you have; if we can't, we'd be sad to see you go, but we certainly don't wish to hold you hostage.
- jmaker 3y ago
  Yes, absolutely, Java’s compatibility story has been stellar. To the point that people got spoiled by it and no longer want to join the more agile release cycle. I’ve experienced folks being more like “oh finally, now I can express myself at least a bit like I got used to with some other language”, so not sure the enhancements you’re mentioning go as far as to put Java apart from its modern day alternatives, at least some of those concepts finally trickled through though. Still, a lot of Java deployments are deliver once, never touch it again, those users would be happy to never upgrade anything. It’s no fun to revalidate the semantics in a large project.
  - pron 3y ago
    > those users would be happy to never upgrade anything. It’s no fun to revalidate the semantics in a large project. Yep, that's why we introduced the LTS service. People may not have noticed before we did away with major releases and changed the version naming scheme, but in the past you had no choice but to upgrade to semi-annual releases with major VM changes, like 8u20 or 7u4 (probably because the name was too similar to patch releases, like 8u30 or 7u5). Now, with LTS, we try to only backport security patches and major bug fixes to make sure that such legacy users get the stability they need.

pron 3y ago

I think that Java's record on compatibility is unmatched, and users are extremely happy with all the enhancements we've been delivering, which why Java's popularity remains sky-high. But no product can satisfy everyone forever, and if you're unhappy, we'd like to try and address the issues you have; if we can't, we'd be sad to see you go, but we certainly don't wish to hold you hostage.

jmaker 3y ago
Yes, absolutely, Java’s compatibility story has been stellar. To the point that people got spoiled by it and no longer want to join the more agile release cycle. I’ve experienced folks being more like “oh finally, now I can express myself at least a bit like I got used to with some other language”, so not sure the enhancements you’re mentioning go as far as to put Java apart from its modern day alternatives, at least some of those concepts finally trickled through though. Still, a lot of Java deployments are deliver once, never touch it again, those users would be happy to never upgrade anything. It’s no fun to revalidate the semantics in a large project.
- pron 3y ago
  > those users would be happy to never upgrade anything. It’s no fun to revalidate the semantics in a large project. Yep, that's why we introduced the LTS service. People may not have noticed before we did away with major releases and changed the version naming scheme, but in the past you had no choice but to upgrade to semi-annual releases with major VM changes, like 8u20 or 7u4 (probably because the name was too similar to patch releases, like 8u30 or 7u5). Now, with LTS, we try to only backport security patches and major bug fixes to make sure that such legacy users get the stability they need.