3 ms·

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

by 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.
- cesarb 6y ago
  > 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 The instability comes not from bugs in the JVM, but from how even tiny changes in the JVM can interact with the software running above it. For instance: Java 15 changed the return value of the getMessage() method of the NullPointerException generated when accessing a null pointer. That shouldn't have made any difference; yet, there is code which accidentally depends on its former return value, and that code is probably in a little used corner of the system where it will break when you least expect. Java 8 is a known variable; you can expect it to have many less breaking changes than chasing the latest Java release (and if you are in the "latest Java release" train, you have to chase the latest Java release, since there's little if any overlap in their support period). It's a solid base for you to build your software on top.
  - dcminter 6y ago
    Yeah, I was going to chip in; there are two kinds of stable. You can say "Java N" is more stable than "Java 8" because they crash less often under fewer circumstances. But you can also say "Java 8" is more stable than "Java N" because we know most of the bugs in "Java 8" already so we can avoid them (and we don't exercise the unknown bugs very often because we'd have worked around them by now if we did). Often that second kind of stability is more important than the other one.
  - pron 6y ago
    > Java 8 is a known variable You might think that, but that's not the case. At least as far as OpenJDK goes, some new features, including huge ones (like JFR) have been backported to it. I believe that the NPE message is being considered for backport, too. > It's a solid base for you to build your software on top. It's old tech, that -- unless you actually buy paid support -- is only partially maintained through backports from mainline only. If you're not buying support, it's a less solid, more risky base than the current version.
  - grandiego 6y ago
    > It's a solid base for you to build your software on top. Agreed. It is what I usually find at client installations in backend systems (at least for the last five years). IMHO it would be pointless to ask them to re-test/re-certify all their already running applications (in turn, specified for Java 8 by their respective providers), with promises about (unrequested) performance gains. BTW, I remember in the past the only way for me to "push" some clients to upgrade from Java 5/6 (to Java 8) was the security/regulatory threat related to running an "unsupported" version of Java: think of the regulatory move from TLS 1.1 to 1.2 and now into 1.3.

by cesarb 6y ago

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.

cesarb 6y ago
> 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 The instability comes not from bugs in the JVM, but from how even tiny changes in the JVM can interact with the software running above it. For instance: Java 15 changed the return value of the getMessage() method of the NullPointerException generated when accessing a null pointer. That shouldn't have made any difference; yet, there is code which accidentally depends on its former return value, and that code is probably in a little used corner of the system where it will break when you least expect. Java 8 is a known variable; you can expect it to have many less breaking changes than chasing the latest Java release (and if you are in the "latest Java release" train, you have to chase the latest Java release, since there's little if any overlap in their support period). It's a solid base for you to build your software on top.
- dcminter 6y ago
  Yeah, I was going to chip in; there are two kinds of stable. You can say "Java N" is more stable than "Java 8" because they crash less often under fewer circumstances. But you can also say "Java 8" is more stable than "Java N" because we know most of the bugs in "Java 8" already so we can avoid them (and we don't exercise the unknown bugs very often because we'd have worked around them by now if we did). Often that second kind of stability is more important than the other one.
- pron 6y ago
  > Java 8 is a known variable You might think that, but that's not the case. At least as far as OpenJDK goes, some new features, including huge ones (like JFR) have been backported to it. I believe that the NPE message is being considered for backport, too. > It's a solid base for you to build your software on top. It's old tech, that -- unless you actually buy paid support -- is only partially maintained through backports from mainline only. If you're not buying support, it's a less solid, more risky base than the current version.
- grandiego 6y ago
  > It's a solid base for you to build your software on top. Agreed. It is what I usually find at client installations in backend systems (at least for the last five years). IMHO it would be pointless to ask them to re-test/re-certify all their already running applications (in turn, specified for Java 8 by their respective providers), with promises about (unrequested) performance gains. BTW, I remember in the past the only way for me to "push" some clients to upgrade from Java 5/6 (to Java 8) was the security/regulatory threat related to running an "unsupported" version of Java: think of the regulatory move from TLS 1.1 to 1.2 and now into 1.3.