3 ms·

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

by 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

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.