3 ms·

I've seen a reluctance to move from Java 8 because of the issues upgrading past Jigsaw (e.g. the build I'm working on today bleeds warnings about groovy doing i

I've seen a reluctance to move from Java 8 because of the issues upgrading past Jigsaw (e.g. the build I'm working on today bleeds warnings about groovy doing illegal reflective access - and that's just a cosmetic issue) and so many shops decided to wait until the "LTS" Java 11 came along to make the jump. Now that they're there and with the memory of the upgrade pain there's reluctance to upgrade again before Java 17. I think once they do that and see a much more normal upgrade path for that leap they'll be a lot more willing to track all the releases and not just the LTS ones (real or not it's perceived as being a thing).

pron 6y ago
I agree. Funnily enough, though, the upgrade pain to 9+ had nothing to do with Jigsaw, because its encapsulation hasn't even been turned on (unless you count warnings). It was just the biggest and most visible change, so people blamed their unrelated upgrade issues on it. The actual cause for many issues was that some popular libraries hacked into off-specification, undocumented JDK internals and relied on them (Groovy did that a lot), and they simply changed, as they're allowed to. The most disruptive specification change was actually dropping the "1." prefix from the version string, that many codebases used to parse. Starting with JDK 16, Jigsaw is finally being fully turned on, and is starting to block access to internal JDK classes unless the application explicitly allows it. Ultimately, this will force libraries not to rely on internal implementation details and so get themselves tied to a specific version.
- dcminter 6y ago
  While I remember, here's a good example of an (IMO) bad decision being made due to the LTS meme: https://lists.ubuntu.com/archives/ubuntu-release/2018-February/004275.html https://lists.ubuntu.com/archives/ubuntu-release/2018-Februa... Point taken about the actual underlying causes of the upgrade pain though. Speaking personally I very much appreciate all the work that goes into delivering OpenJDK and I think some of the anti-Java groupthink that exists on HN is regrettable.
  - abraae 6y ago
    I suspect there is a silent majority who enjoy Java's industrial reliability, its longevity, and the sheer volume of libraries and online resources, and can't be bothered raising their heads above the parapet every time someone starts ranting on about how crap OOP is.
AtlasBarfed 6y ago
Did they ever resolve sun.misc.unsafe replacement since it was being deprecated/removed at some point? Basically every high performance app uses that to bypass the vagaries of GC. It may not impact a day-to-day enterprise dev, who is going to be behind by 8 versions for years due to the issues with enterprise IT deployment/policy/management/prioritization. I have to hand it to Oracle, this every six months release thing was a brilliant way to squeeze money from customers and absolutely screw over the OSS users and ecosystem in the long run. Google/Android or Amazon could have acquired Java for decimal points of yearly revenue. Likely less than google's legal fees.
- dcminter 6y ago
  As someone who very much felt the pain of stagnation in Java during the long release-cycles of the Java 5 to 8 era, I'm wildly enthusiastic about the new six-monthly release cycle. Most of my clients use OpenJDK and don't pay for support of Java per se, so there are plenty of us outside the blast radius enjoying the benefits.
- dcminter 6y ago
  I can't find a reference off hand, but from following along the JDK-Dev mailing list the philosophy is not to remove sun.misc.unsafe until all the features are available in other public APIs. They're well aware of how important it is. Hopefully someone else can chip in with a better reference or I can find an appropriate cite to back this up. Edit: Ah, here's an example: https://openjdk.java.net/jeps/396 https://openjdk.java.net/jeps/396 > It is not a goal to remove, encapsulate, or modify any critical internal APIs of the JDK for which standard replacements do not yet exist. This means that sun.misc.Unsafe will remain available.
- pron 6y ago
  sun.misc.Unsafe has not been removed or blocked, and yes, there's also safe replacements -- VarHandles and the foreign memory API -- for much of its functionality, which will be removed piecemeal. > I have to hand it to Oracle, this every six months release thing was a brilliant way to squeeze money from customers and absolutely screw over the OSS users and ecosystem in the long run. Huh? How? We've open sourced the entire JDK, making it -- for the first time in Java's 25-year history -- 100% open-source, and we did away with major releases altogether, keeping only the minor ones, and making upgrades cheaper and easier. It's true that some people have not yet internalised what the change means, though. All change is scary, but this one is definitely better for users and for FOSS Java.
cesarb 6y ago
> and so many shops decided to wait until the "LTS" Java 11 came along to make the jump Even if they didn't decide to wait, they had to wait until all libraries they depend on made the jump. Many of them took a long time (as late as last year, I was still seeing "fix something which breaks in Java 9" in library changelogs), and sometimes the compatibility with Java 9 was only available on a newer major release of the library, which sometimes required upgrades to major releases of other libraries, and so on, and to make it even more painful some of these major releases dropped support for older Java releases like Java 7, which some of your clients might be using. Migrating to Java 11 was actually more painful than migrating to Java 9, since Java 11 removed some of the things deprecated by Java 9 (this was a very short deprecation cycle, only one year between deprecation and removal), like all of J2EE; and IIRC, not all of the removed things were available as separate libraries (for instance, I recall CORBA being listed as not available separately, so once it was removed from the JVM, there was no alternative if you depended on it). And there's the fact that, if you expect to run on the default-installed JVM in the latest release of a popular enterprise Linux distribution, you have to keep compatibility with Java 8. So all this pain is for next to zero gain (the only real gain is some GC improvements, if your client is willing to risk using Java 11 and encountering obscure bugs in your software).
- pron 6y ago
  Well, the main gain we're seeing that attracts most companies is money, sometimes lots of it. Savings on hardware due to performance and footprint improvements are often so large that they very quickly offset any migration costs. Here's a pretty common experience from LinkedIn: https://youtu.be/1AYTFRUTyao?t=14411 https://youtu.be/1AYTFRUTyao?t=14411. Systems that don't migrate are usually those that carry little hosting costs and/or make little money. Second, as someone who works on OpenJDK I can tell you that the belief that JDK 8 is more stable than 15 (or even 11) is misguided either based on how they're actually maintained (an order of magnitude more people maintain 15 than 8, and while they backport some fixes, they don't backport them all, and we've had a few incidents of bugs introduced through misapplied patches) and the actual bug data. It is true that some new features might be less stable, but it's safer, at this point, to use 15 (or 11) than 8.

pron 6y ago

I agree. Funnily enough, though, the upgrade pain to 9+ had nothing to do with Jigsaw, because its encapsulation hasn't even been turned on (unless you count warnings). It was just the biggest and most visible change, so people blamed their unrelated upgrade issues on it. The actual cause for many issues was that some popular libraries hacked into off-specification, undocumented JDK internals and relied on them (Groovy did that a lot), and they simply changed, as they're allowed to. The most disruptive specification change was actually dropping the "1." prefix from the version string, that many codebases used to parse. Starting with JDK 16, Jigsaw is finally being fully turned on, and is starting to block access to internal JDK classes unless the application explicitly allows it. Ultimately, this will force libraries not to rely on internal implementation details and so get themselves tied to a specific version.

dcminter 6y ago
While I remember, here's a good example of an (IMO) bad decision being made due to the LTS meme: https://lists.ubuntu.com/archives/ubuntu-release/2018-February/004275.html https://lists.ubuntu.com/archives/ubuntu-release/2018-Februa... Point taken about the actual underlying causes of the upgrade pain though. Speaking personally I very much appreciate all the work that goes into delivering OpenJDK and I think some of the anti-Java groupthink that exists on HN is regrettable.
- abraae 6y ago
  I suspect there is a silent majority who enjoy Java's industrial reliability, its longevity, and the sheer volume of libraries and online resources, and can't be bothered raising their heads above the parapet every time someone starts ranting on about how crap OOP is.

AtlasBarfed 6y ago

Did they ever resolve sun.misc.unsafe replacement since it was being deprecated/removed at some point? Basically every high performance app uses that to bypass the vagaries of GC. It may not impact a day-to-day enterprise dev, who is going to be behind by 8 versions for years due to the issues with enterprise IT deployment/policy/management/prioritization. I have to hand it to Oracle, this every six months release thing was a brilliant way to squeeze money from customers and absolutely screw over the OSS users and ecosystem in the long run. Google/Android or Amazon could have acquired Java for decimal points of yearly revenue. Likely less than google's legal fees.

dcminter 6y ago
As someone who very much felt the pain of stagnation in Java during the long release-cycles of the Java 5 to 8 era, I'm wildly enthusiastic about the new six-monthly release cycle. Most of my clients use OpenJDK and don't pay for support of Java per se, so there are plenty of us outside the blast radius enjoying the benefits.
dcminter 6y ago
I can't find a reference off hand, but from following along the JDK-Dev mailing list the philosophy is not to remove sun.misc.unsafe until all the features are available in other public APIs. They're well aware of how important it is. Hopefully someone else can chip in with a better reference or I can find an appropriate cite to back this up. Edit: Ah, here's an example: https://openjdk.java.net/jeps/396 https://openjdk.java.net/jeps/396 > It is not a goal to remove, encapsulate, or modify any critical internal APIs of the JDK for which standard replacements do not yet exist. This means that sun.misc.Unsafe will remain available.
pron 6y ago
sun.misc.Unsafe has not been removed or blocked, and yes, there's also safe replacements -- VarHandles and the foreign memory API -- for much of its functionality, which will be removed piecemeal. > I have to hand it to Oracle, this every six months release thing was a brilliant way to squeeze money from customers and absolutely screw over the OSS users and ecosystem in the long run. Huh? How? We've open sourced the entire JDK, making it -- for the first time in Java's 25-year history -- 100% open-source, and we did away with major releases altogether, keeping only the minor ones, and making upgrades cheaper and easier. It's true that some people have not yet internalised what the change means, though. All change is scary, but this one is definitely better for users and for FOSS Java.

cesarb 6y ago

> and so many shops decided to wait until the "LTS" Java 11 came along to make the jump Even if they didn't decide to wait, they had to wait until all libraries they depend on made the jump. Many of them took a long time (as late as last year, I was still seeing "fix something which breaks in Java 9" in library changelogs), and sometimes the compatibility with Java 9 was only available on a newer major release of the library, which sometimes required upgrades to major releases of other libraries, and so on, and to make it even more painful some of these major releases dropped support for older Java releases like Java 7, which some of your clients might be using. Migrating to Java 11 was actually more painful than migrating to Java 9, since Java 11 removed some of the things deprecated by Java 9 (this was a very short deprecation cycle, only one year between deprecation and removal), like all of J2EE; and IIRC, not all of the removed things were available as separate libraries (for instance, I recall CORBA being listed as not available separately, so once it was removed from the JVM, there was no alternative if you depended on it). And there's the fact that, if you expect to run on the default-installed JVM in the latest release of a popular enterprise Linux distribution, you have to keep compatibility with Java 8. So all this pain is for next to zero gain (the only real gain is some GC improvements, if your client is willing to risk using Java 11 and encountering obscure bugs in your software).

pron 6y ago
Well, the main gain we're seeing that attracts most companies is money, sometimes lots of it. Savings on hardware due to performance and footprint improvements are often so large that they very quickly offset any migration costs. Here's a pretty common experience from LinkedIn: https://youtu.be/1AYTFRUTyao?t=14411 https://youtu.be/1AYTFRUTyao?t=14411. Systems that don't migrate are usually those that carry little hosting costs and/or make little money. Second, as someone who works on OpenJDK I can tell you that the belief that JDK 8 is more stable than 15 (or even 11) is misguided either based on how they're actually maintained (an order of magnitude more people maintain 15 than 8, and while they backport some fixes, they don't backport them all, and we've had a few incidents of bugs introduced through misapplied patches) and the actual bug data. It is true that some new features might be less stable, but it's safer, at this point, to use 15 (or 11) than 8.