/me nervously glances at all the production infrastructure I manage that's still on JDK 7 or 8.
I've just recently been able to upgrade some things to JDK 11.
I've just recently been able to upgrade some things to JDK 11.
I got the impression (but please correct me if I'm wrong) that only this year most major libraries got all the kinks worked out for Java 11. In particular, when using them together.
Guice is one that only recently got the nasty (but relatively harmless) warning you get when using it with Java 11 under control.
Java 17 is the next long term support release, so most of us working on longer lived code bases will probably skip all the releases in between. It doesn't seem worth the effort, because if the Java 9 and 10 experience is anything to go by, you will be hunting down issues with Maven plugins, transitive dependencies, and libraries holding back for now all day.
Personally I've dropped guice and just stick to Weld anymore since it's the reference implementation of the standard. I haven't had any problems running it on JDK 14.
You had issues with 10? The only issues I got were with Java 9, because introduction of modules broke some stuff. Later it was just making sure that ASM or aspectj/lombok is in the most recent version that has new JDK version added, which might have been a problem in 10 (I know I was trying to upgrade on day 1).
But nowadays, all the most popular libraries are on par with the next Java version that is in the works at least a month before the release.
Since JDK 12, I just do an upgrade every 6 months and had no issues so far.
And if you don't ship software to clients then there is almost no downsides to upgrading and a lot of upsides.
If you do ship software to clients you should be using jlink, this way you ship smaller binaries and clients don't need to worry about JDK, because you will provide it to them .
And you also need to lookup what LTS means in case of Java - it is not the same as in e.g. Ubuntu.
In Ubuntu you get free of charge fixes in LTS, in Java you need to buy an LTS version from someone (they will make fixes there) OR use the latest JDK version (which gets all the fixes free of charge).
Plus, keep in mind that LTS is a paid service. What appears to be "free LTS" isn't really LTS, but builds of the OpenJDK Updates projects. Those builds serve as the basis for various paid LTS offerings, but in themselves they don't actually maintain the full JDK. OpenJDK Updates just backports stuff from the mainline version. If you're using a component that's been removed from the mainline -- and you probably do or else you'd upgrade -- then that component is not maintained in OpenJDK Updates (so-called "free LTS") because there's nothing to backport from.
The only version that's 100% maintained for free is the current JDK (15 as of today).
If you're using one of those "free LTS" distributions you should know that you're using a JDK that's not fully maintained. The only JDK version that's fully maintained completely free is the current version. To be fully safe and run maintained software you can either use the current version for free or use an old version and pay someone for LTS.
Maintaining a JDK is a lot of work. There are a couple of hundred full-time developers working on OpenJDK tip and maintaining the current release; there are ~10 full-time engineers (probably less) from all companies combined maintaining both OpenJDK 8u and 11u. For real support for an old version you must pay.
(I work on OpenJDK at Oracle)
The thing is that the money saved in hardware/hosting by running the current version would more than pay for any update costs. By using the current version, companies will be using better maintained software and paying less money for it. Those "free LTS" builds, which aren't really LTS, is a mind game that keeps companies on old versions that cost more money to run in the hopes that people will ultimately pay for real maintenance, perhaps once they fall behind too far.
1) OpenJDK Updates binary builds: they take the source code of the project, build it, and provide binaries. Examples I know are AdoptOpenJDK and the free Azul OpenJDK distribution.
2) Open source LTS: they take the OpenJDK Updates project, then add bugfixes they did for their PAYING customers. They publish the source code of the result. Here I see RedHat OpenJDK (such as the OpenJDK 8/11 builds distributed with RHEL 7/8). Those are then made available for free in binary form as well, such as part of CentOS. If you want a big fixed in those versions you have to pay, but you can benefit from bug fixes made for others. "LTS" here means as long as the RHEL version lives.
3) Paid LTS with custom support. Those do the same as 2, but don't release the source or binaries to the public, only to paid customers. Maybe there are even custom builds for specific customers. That would be Oracle mainly, and Azul and IBM as well.
What's unclear to me is if fixes from 2 flow into 1. Also, I don't know which kind Coretto is (Probably 1).
Is that a correct assessment of the situation?
There are other differences, too. Adopt, made by a particularly amateurish team at IBM that is barely involved with the OpenJDK project and quite unfamiliar with its workings, isn't a member of the vulnerabilities team and so gets access to security fixes later than all other vendors (and that's not the only thing that makes their build more problematic than all others). Among those that do participate in OpenJDK to varying degrees, including Amazon, there are differences in how much of the changes to their branded forks they upstream to OpenJDK Updates (RH upstreams more; Azul less).
Anyway, the important thing to know is that there is only one version that is fully supported for free -- the current one, and so the safe choices are either some paid LTS or the current version.
> Anyway, the important thing to know is that there is only one version that is fully supported for free -- the current one, and so the safe choices are either some paid LTS or the current version.
It looks like overstatement for me but reasonable perspective for Oracle employee.
Size isn't the only issue. Version number of fetishism is very much a thing in large companies. Megacorps and banks are very slow to update. I can't tell my customers to switch to Java 15 tomorrow (or even next year). Especially after the complexity of upgrades to 9 and 11, both of which broke things in many subtle ways. This may not be an issue for many applications, but it was certainly an issue for us and our customers.
I admit that doing away with major releases, giving the feature releases new version names, and the last ever major release was too much all at the same time and is confusing. But the payoff in learning what actually happened is big, as is the loss in not. Your customers might be losing both time-to-market and serious money for a lack of a day's worth of education. They can start here: https://blogs.oracle.com/java-platform-group/update-and-faq-...
[1]: The only version for which you get free support from anyone is the current version. No one offers free LTS for old versions. https://news.ycombinator.com/item?id=24487298
That might not sound too important but it has an effect on GC chosen amd obviously how you might have tuned your thread pools.
By now, I'd say if you depend on a library that still doesn't work on JDK9+ you should replace it, but depending on your requirements that may not be so easy and so some people are still stuck on JDK8.
I have tests that use JSON serialization and deserialization (and then some), and they pass perfectly fine on Java 8 runtime, but fail in exactly same place on Java 11, without recompilation. I have spent some non-zero time trying to get to the bottom, but so far without much luck.
In theory yes.
In practice the plugin and scanning systems the software I use has had a multitude of failures between JDK8 and 11.
The Hadoop ecosystem has definitely been dragging its feet on JDK bumps.
[0] https://github.com/apache/spark/blob/master/resource-manager...
And in the particular case of Java 9, they decided to deprecate several things, and quickly removed them in Java 11 (that is: with less than a year warning, and no warning if you follow only the long-term versions). That includes a lot of J2EE classes which previously came with the JRE, and now became external dependencies (with the most recent version of these external dependencies sometimes having slightly different behavior).
For example, in addition to the module system, Java 9 changed the implementation of some of its XML rendering libraries and caused meaningful behavior changes.
https://github.com/CodeFX-org/java-9-wtf has a list of some of the stuff that broke.
That said, 8 -> 9 was the only really painful transition in my experience. Since then the upgrades have been smoother.
The only free of charge LTS is the latest java version, all versions n-1, n-2 are out of free support, you can only buy one.