AdoptOpenJDK 8u265 Available | Hacker News Reader

AdoptOpenJDK 8u265 Available

blog.adoptopenjdk.net

44 pointsbased231 comments

Save someone some googling if they don't know what AdoptOpenJDK is --> https://developer.ibm.com/technologies/java/blogs/adoptopenj...

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

AIUI, Oracle provides:

1. "Oracle OpenJDK": free, open source builds of the current version of OpenJDK, at https://jdk.java.net/

2. "Oracle JDK": expensive, licensed builds of several versions of OpenJDK (plus their special patches?), at https://www.oracle.com/java/technologies/javase-downloads.ht...

See:

https://developer.okta.com/blog/2019/01/16/which-java-sdk

You can't get a maintained build of 11, the current LTS, from Oracle for free. Hence, AdoptOpenJDK and some other players provide that.

I keep meaning to look into Corretto, Amazon's patched build of JDK 8 and 11:

https://aws.amazon.com/corretto/

Amazon use it internally, so it is battle tested, and their 8 version has loads of good patches:

https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/pa...

11 is pretty vanilla right now, but could get better with age.

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.

pron98 (pron on HN I believe) who works on the JDK at Oracle explains it better here: https://www.reddit.com/r/java/comments/i5zyyk/wtf_does_lts_e...

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.

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.

https://www.infoq.com/presentations/life-after-java-8/

Https://www.adoptopenjdk.net/about.html gives a better picture

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.

Well spotted. Surprised no-one even mentioned this in the comments there.

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.

I had a vague idea that Red Hat was in some sense now responsible for Java 8:

https://developers.redhat.com/blog/2018/09/24/the-future-of-...

But that particular bug was backported by someone at Oracle.

One of the Red Hat engineers (Andrew Haley) is the lead of jdk8u but that’s officially him as an individual as opposed to RH the company

Amazon is also pretty active maintaining v8 with Amazon Coretto. Red Hat, Azul also provide certified builds to their customers.

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.

Probably security concerns took priority over compatibility.

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 did not found the release note for this version.

Here the previous greatly detailled one: https://adoptopenjdk.net/release_notes.html

8u265b10 and brew now provides 8u265b01?

https://github.com/AdoptOpenJDK/homebrew-openjdk

Yeah my bad - that ticket is assigned to me, should get it done this weekend

Couldn't find any 8u265 binaries to download. Am I missing something? In what sense is it "available"?

I love how they always push OpenJ9. Guess that's just IBM.

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.

It's sad if that is the case because OpenJ9 is such a good alternative to Hotspot IMO.

... "somewhere" perhaps being here[1][2], where it's speculated that the issue is the technicality that OpenJ9 is Apache/Eclipse licensed and not GPL.

[1] https://twitter.com/volker_simonis/status/105261065466907443...

[2] https://news.ycombinator.com/item?id=19826967

Reply on news.ycombinator.com