I think this still leaves out some important details. Oracle's OpenJDK is source code only - you have to build it yourself. AdoptOpenJDK provides pre-built binaries ready for use.
I was a little confused about this for a long time especially when AdoptOpenJDK was first created, but I believe this is wrong. Here is an OpenJDK build from Oracle: https://jdk.java.net/14/
I think you have it slightly wrong. LTS is not a thing inherent to the language or to OpenJDK, it is a thing that a vendor provides. It is separate from from "update" releases that Corretto and AdoptOpenJDK provide.
It's true that I'm using "LTS" very sloppily. Last time I looked into this in depth, it wasn't at all clear how community/third-party maintenance of old versions was going to be handled. It still isn't entirely clear.
It's certainly true that "LTS" is not an official thing for OpenJDK or Oracle. But if Red Hat is doing LTS for 11, and are upstreaming their patches to the OpenJDK updates repo, then LTS is a thing in practice. Even if AdoptOpenJDK aren't doing any backporting, just building OpenJDK, that's functionally an LTS.
The comment you link to is astoundingly bad, given who it's from. In particular:
> The safest, easiest approach is to use the current JDK. You get a well-maintained JDK and never have to do another major upgrade.
No, you may have to do a major upgrade every six months.
> No, you may have to do a major upgrade every six months.
I think the point is that it's not a major upgrade. There hasn't been a major upgrade since 9, and there won't be going forward. It's similar to Go in that sense, where it's very easy to upgrade to the latest version, and older versions are only supported for a year.
The 9 -> 10 -> 11 upgrades are allowed to make breaking changes. I have apps running on 11 that i can't upgrade further without significant work, because there are things that were retired in 12.
To me, that means those changes are major upgrades.
pron's article says that there are no major releases, only feature releases, and that may well be the terminology the project uses, but that terminology is pure mendacity.
I might well be wrong. I wrote what I surmised as the situation after following lots of links for five minutes. Your comment certainly confirms there’s a lack of clarity around AdoptOpenJDK. I’d like to be better educated about it.
Azul's Gil Tene has a nice talk about the various JDKs available and why one would want to keep up with the recent (more frequent than usual) releases.
It's great to see even incremental performance fixes are still getting backported (eg: https://bugs.openjdk.java.net/browse/JDK-8229022). I am curious how long that will be maintained as it must surely be quite a bit of effort.
The backporting work is being done by Oracle, right?
I imagine there could be some risk-averse Java-powered companies out there willing to pay good money to keep their old JVMs patched, to avoid the risks of upgrading.
> some risk-averse Java-powered companies out there
There millions of them. But if anything I would expect that risk aversion to translate into not back porting discretionary performance fixes. For example, the fix I linked to improves BufferedReader performance by swapping a thread-safe underlying class for a non-thread-safe version. That could introduce race conditions and other synchronization issues into its behavior. Thread safety was never specified in the API so that's fine for prospective versions, but having this land unexpectedly in a minor version update bundled with security patches .... is almost the opposite of what I would want.
It is a method-scoped variable that is operated on under the reader's lock. Therefore the additional locking by StringBuffer is unnecessary and there is no negative impact by switching to StringBuilder.
You're right - it makes me feel a bit better. But the underlying point ... that I'm surprised this sort of thing is getting backported, I think is still the same.
Careful with these patch releases as they often introduce breaking changes. Java update 11.0.6 recently broke all self-signed certs because they introduced new behavior, and required a config change to enable the old behavior. Test before you roll them out!
> A new system property named jdk.security.allowNonCaAnchor has been introduced to restore the previous behavior, if necessary.
Hmmm Java is normally super backwards compatible, even leaving in deprecated API's for several major versions. I wonder what the reasoning behind this change was.
Odd that they would patch out of schedule. Usually would expect this on the third week of January, April, July, and September with the normal TLS schedule.
I think I heard somewhere (please correct me if this is merely a malicious rumor) that the reason AdoptOpenJDK were denied a license to the official test suite (TCK) was that Oracle were not happy that OpenJ9 was offered as an option. Guess everyone else fell in line.
