BTW, LTS is mostly designed for legacy applications, i.e. those that don't see much development. The recommended version for use in production by applications that are heavily maintained is always the current version (15, and soon 16). It is true, however, that many people still misunderstand Java's LTS, and perhaps confuse it with the notion of LTS in other ecosystems, and so many choose an old version and buy LTS even if it's not the best option for them.
(I work at Oracle on OpenJDK)
I believe you, but that message isn't front and center on the various OpenJDK distributions.
If we define LTS to at least include long-term maintenance in the form of bug and security fixes of the entire JDK, then no one offers a free LTS. Free offerings that call themselves LTS are just builds of the OpenJDK Updates project, that backports fixes from mainline, and so only includes fixes for the intersection of the old version and the current one (i.e. no "free LTS" offers patches for, say, CMS or Nashorn, and multiple other components that exist in 11 or 8 but not in 16). "Free LTS" offerings are only recommended for legacy hobby projects. Important production software should use either the current version (free) or buy an LTS service for an old version from some trusted vendor. The only version that is fully and freely maintained is the current one, and it also offers the cheapest upgrade process and the best performance. Don't think that if the vendor calls something LTS and ships updates that include some fixes you're actually getting some fully-maintained JDK.
BTW, AdoptOpenJDK is not affiliated or involved with OpenJDK, and is made by an IBM team that is exceptionally uninvolved and unfamiliar with OpenJDK compared to all other OpenJDK distributions (Oracle, Red Hat, SAP, Azul, Bellsoft, and Amazon).
https://www.phoronix.com/scan.php?page=article&item=openjdk-...
https://www.phoronix.com/scan.php?page=article&item=graalvm2...
(edit: added missing version (slighly embarassed) and second link)
Moving away from 8 results in a significant saving in hardware/hosting costs for the vast majority of large applications.
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).
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.
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.
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).
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.
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.
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.
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.
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.
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.
> 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.
I get for startups or people running immediate-to-production deployments that it is doable.
But Java's ecosystem is boring, staid enterprise, and those people are still running critical systems on Windows XP or worse. IF they are dragging their feet on THAT...
The churn basically stuns these people into 1) staying on Java8 for a LONG time, or 2) look at rewriting the system in something else, or 3) scaring them into paying money.
I have been doing mostly groovy for the last 10 years so not a single feature in the Java besides invokedynamic (which was really a JVM feature not a Java feature) has impacted me in a good way. Meanwhile... that churn.
As a Cassandra user I have seen the "what the hell do we target" conversation play out for 4.0 planning on the dev list, besides the sun.misc stuff. Maybe since (gah AMAZON's Corretto, seriously we have to rely on AMAZON being a good steward of OSS) then the coordination of patching and providing builds has stabilized outside of Oracle offered downloads, but it was a bit unsettling for a while.
So while I get that a lot of people see that as "being nimble" and "moving fast", those are precisely NOT what Java has historically been, for better or worse.
As to the changes, they aren't "near breaking." There have been few breaking spec changes, and they were very small. What breaks is what had always broken code: reliance on internal undocumented classes that change. The reason this happens more now than in the past is not due to spec backward compatibility -- we're as compatible as ever for most intents and purposes -- but because Java was stagnant for a good while, starting with Sun's dying days, and Oracle has been steadily increasing investment in the platform, which means more work done, which means more implementation changes. I think few would say this is a bad thing, but it also means that more code that does what it's warned not to do -- breaks. We're trying to stop this by turning on encapsulation in JDK 16, which would gradually stop libraries from hacking into the JDK and becoming stuck at any specific version.
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.
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
> 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.