AdoptOpenJDK: Open-source, prebuilt OpenJDK binaries | Hacker News Reader

AdoptOpenJDK: Open-source, prebuilt OpenJDK binaries

adoptopenjdk.net

141 pointsnnnmnten86 comments

Open articleView on HN

On macOS and Windows their various builds are also available over the Homebrew and Scoop package managers:

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

https://github.com/lukesampson/scoop/wiki/Java

And SDK Man, which is fantastic:

https://sdkman.io/

SDKMan is a thing of beauty. Completely changed the way I work with the Java ecosystem.

Thanks for this. I've been using Jabba[0] for Java which works pretty well, but I'd be curious to check this out. Although I don't know about everything SDKMAN supports, but it seems a lot of these are better handled elsewhere in most cases. For example, Maven via mvnw, gradle via gradlew, sbt can specify its own version, etc. That said, I'm sure there are good use cases for managing these things via SDKMAN.

[0] https://github.com/shyiko/jabba

You don't need extra projects to manage this stuff anymore.

There is a great answer here... https://stackoverflow.com/questions/52524112/how-do-i-instal...

  brew install java (12)
  brew install java11

And you can simplify things...

In your .bashrc:

  export JDK_HOME=`/usr/libexec/java_home -v 12` # v9+ change to the version you installed
  export JAVA_PATH=$JDK_HOME
  export JAVA_HOME=$JDK_HOME
  export PATH="."
  export PATH="${PATH}:${JAVA_HOME}/bin"

Incredible, thanks for sharing this.

Homebrew is only useful for macOS users though sadly.

Homebrew will work on Linux and the Windows Subsystem for Linux as well. I'm not sure how well it works there, though, as I've only used it on macOS.

https://docs.brew.sh/Homebrew-on-Linux

On Arch Linux, OpenJDKs from 8 through 12 are packaged in the main repositories, and there's a convenient shell utility for switching them (with symlinks, rather than environment variables, so that you can change the default in shells that have already started).

I'm a big fan of SDKMan for handling my Java/Kotlin/Gradle releases. It works across all the major platforms. Homebrew is great on macOS, but kinda non-existent on other platforms.

I use it together with jenv so I can switch between versions easily. Jenv does not allow you to install versions. Sdkman makes it hard to switch between versions but together they solve the problem.

Huge fan of SDKMan. Just wish it was friendlier with Windows.

RedHat also provides OpenJDK builds for free, although hidden behind a developer account registration.

https://developers.redhat.com/products/openjdk/download

Red Hat also provides binaries built from the unmodified OpenJDK source here: https://adoptopenjdk.net/upstream.html -- which could be downloaded without developer account.

AdoptOpenJDK is sponsored by RedHat (among others).

One of the company with large contribution to the AdoptOpenJDK is jClarity. jClarity got purchased by Microsoft a few days ago. Are we seeing MS more involvement for JDK development from now on? They are pushing it big for .NET platform but the JVM consumption is a huge market opportunity. With MS strategy of going all in in cloud computing, supporting the JVM is a no-brainer to me.

Honest question, do any of the current jClarity employees actually do upstream OpenJDK development? I know they build tools around Java but I'm not aware that any of the current employees take part in upstream OpenJDK development eg. at least have a JBS account. Maybe I'm just misinformed.

From what I know, jClarity is only contributing financial support to the AdoptOpenJDK platform: build farm, hosting binaries. I don’t think they do backport of securities or bug fixes for expired releases like Redhat or Amazon does.

We had started to submit actual patches and work yes, that will now increase at MSFT. (ex jClaritt CEO here)

Anyone ever tried the Eclipse OpenJ9 VM? I've never heard of it, but it might be fun to see if there's a difference with my various apps and performance in an IDE.

I've just been hearing a lot of fuss about GraalVM, though haven't had time to investigate what's so special about it nor how it might help typical 'enterprise' services and Java apps.

I have used really old versions of J9 on StrongARM systems, it was faster than the Sun JVM at the time as there was no JIT for the Sun one.

I used it as a replacement for openjdk 8, and I was very happy with the results. Keep in mind there are a few attributes that differ, but the documentation was very clear on that.

Just note that, while the download page is confusing about this point, the OpenJ9 distribution is not OpenJDK; it's a completely separate project, albeit one that copies much of the OpenJDK code. OpenJDK release notes are largely irrelevant to the OpenJ9 build.

Yes, as part of Websphere.

It was quite good in the past and one of the first to support JIT caching.

Never used it after it went open source though.

Does the OpenJDK project not offer open source, pre-built binaries already?

I think they do, but Oracle recently announced they won't be backporting security patches to older versions of the open source OpenJDK distributions. As I understand it AdoptOpenJDK is a third party effort to continue supporting the free verisions of older versions of java after Oracle abandons them.

No. It's a source-only project. Various companies and organization provide both certified and uncertified builds. There are certified builds from Oracle, Red Hat, SAP, Azul (Amazon and Alibaba provide builds of OpenJDK forks), and uncertified builds from Adopt (that also provides OpenJ9 distributions, which are very much not OpenJDK).

There are many OpenJDK(-based) distributions out there, mostly built from the OpenJDK {8, 11} Update Releases sources. AdoptOpenJDK provides one of those distributions.

Most of the actual backport work is done by the OpenJDK participants, notably people from Red Hat (like me), SAP, Amazon, Azul and others. Oracle does not participate in OpenJDK 8u/11u directly, opting to maintain their separate tree, from which they build Oracle JDK 8u/11u available under the commercial license. There is also a security collaboration between many companies (OpenJDK Vulnerability Group), which drops its deliverables in relevant source trees.

At one point, I tried to draw this map to show the bird's eye view on the landscape: https://shipilev.net/jdk-updates/map/ -- you can find AdoptOpenJDK there.

What gets people confused is http://openjdk.java.net/ linking to Oracle distribution (either at jdk.java.net, or Oracle site). That might be seen as "OpenJDK providing the binaries", but it is actually not: it links to one of the distribution providers.

Well, maybe not directly, but the code you diligently backport does come mostly from Oracle. ;)

Granted, Oracle does contribute lots of code. As the result, lots of Oracle-created code gets backported too. That said, I see people backport a lot of code/tests that they wrote themselves, and/or with the help of non-Oracle contributors. For example, Red Hat, SAP, Huawei backport a lot of code to maintain the target platforms they own (e.g. AArch64 and PPC), or their components (e.g. diagnostics support, Shenandoah), or their build environments. While I understand the desire to pitch Oracle here, it would be awkward to do so by undervaluing the contributions of others at the same time.

I am not undervaluing anyone's contribution. Many companies contribute a lot of valuable work, and we at Oracle are thrilled to cooperate with them and actively encourage them to contribute more, but Oracle does currently contribute ~90% of the work on OpenJDK. So many companies and independent developers deserve full credit, but Oracle is in a separate category, contributing as much as all others combined, several times over. This explains why Oracle has opted to offer only paid support for those opting to stay on old JDK versions: this is how Oracle funds lion's share of OpenJDK's development.

BTW, the recommended path is free perpetual support by using the current JDK version that, under the new gradual release model, means you'll never have to do another major upgrade again. Staying on old JDK versions will be more expensive, even if you're using a free distribution.

Oracle is in a separate category, no question there.

It was my mistake to mention other vendors in the thread that is about AdoptOpenJDK. I just wanted to show where the AdoptOpenJDK sits in the larger OpenJDK ecosystem: they are important builders and distributors.

> the recommended path is free perpetual support by using the current JDK version that, under the new gradual release model, means you'll never have to do another major upgrade again.

Implying applications always receive continued development...

This has always been true, and also true for those that stick to LTS. If you want to receive security patches, you need to update your JDK. BTW, as the new deployment approach is to create a custom minimal runtime and bundle it with your app, your application may not need security patches, depending on what it does.

Oracle does not provide Java 8, so they are unreliable vendor. It's better to use more reliable sources which do not drop the version that the whole world still uses and will use for many years.

Yes, they do here

https://adoptopenjdk.net/upstream.html

Note that these are different binaries, build by RedHat not by AdoptOpenJDK. They are distributed there because the Java 8 and Java 11 OpenJDK projects are not allowed to post builds on https://jdk.java.net.

Another good alternative is Azul Open JDK build.

I assume this is mostly for windows? All Linux and I assume Mac has openjdk available in the repos. The openjdk project itself also hosts binaries for *Nix

It can be helpful to just pull binaries from AdoptOpenJDK when you know you want a very specific version.

System packages shift around minor versions which is fine 99% of the time (given Java's compatibility especially). I've occasionally needed to work around a bug in a specific version.

Homebrew uses adoptopenjdk.

In windows you have chocolately. (The brew equivalent of windows)

Oracle's OpenJDK binaries are here: http://jdk.java.net/

At least the MacOS binaries from Oracle are not packaged in a user-friendly manner. You just get a zip file containing JAVA_HOME, and it's up to the user to know what to do with this.

Apple requires you to copy this to a very specific, deeply nested, hidden system directory.

That's definitely not something I could ask an end user to deal with.

After the bait and switch with the licensing for the original Java distribution, I'm not comfortable downloading anything from Oracle anyway. It's just too risky.

What requirement does Apple put on the JDK location? All of mine are in ~/lib/* and are easy to manage. JENV for bonus points. Definitely not a double-click-install experience, but not hard to figure out for anyone with a bit of terminal experience.

If you want it to be recognized by the system as a valid runtime for Java apps, I believe it needs to be in /Library/Java/JavaVirtualMachines/jdk${VERSION}.jdk/Contents/Home/.

The JDK requires no installation, and the concept of a "desktop system JRE" is no longer recommended; in fact, a JRE is no longer shipped. The recommended practice is for developers to bundle a custom, minimized version of the runtime with their application (using jlink). End users shouldn't install any Java runtime anymore.

> After the bait and switch with the licensing for the original Java distribution

The product known as OracleJDK used to be part free, part commercial, based on which features you used. JRE downloads also used to contain that annoying search toolbar. What we at Oracle have done is completely open-source the JDK, for the first time in its history, and release it under two licenses: a free license, and a license for those who wish to buy support. There is a large clear warning on each download page guiding people to the distribution they need. I think most people agree that this is a very welcome change, and I see no bait and switch.

I know desktop system JRE's aren't recommended any more, but there's still plenty of apps out there that require them. I literally ran into this last week.

I am glad to hear the toolbar on the JRE is gone, and I'm glad there's a prominent notice on the download pages - but there's effectively no free official standalone JRE for commercial use anymore.

That's because a system JRE is the old way of doing things -- and moving away from that wasn't arbitrary; desktops are encouraging app stores, and servers are using containers -- and we want our OpenJDK developers (I'm one of those) to focus on the new way of doing things. Oracle doesn't have control over an ecosystem that could generate billions, like Google with Android or Apple with iOS, so to pay the hundreds of full-time developers who develop OpenJDK, we charge those who want to do things the old way for support. So if you don't want to switch to the new way of doing things, you have a few options:

* Download a JRE with an installer from someone else who builds and distributes it; I don't know about certified distributions, but I think Adopt ships something JRE-like.

* Buy support from Oracle (and help fund OpenJDK's development).

* Build a JRE yourself from the JDK and package it with an installer.

I think that's reasonable.

Without installation on Windows `Preferences.systemRoot();` writes bunch of log errors in stderr. It tries to create HLKM\Software\JavaSoft\Prefs. Installer creates that registry node, so it works just fine after that. I don't know if it's a bug or intended behaviour.

Which version are you using? This could be this issue[1], fixed in 9.

[1]: https://bugs.openjdk.java.net/browse/JDK-8139507

I checked on latest 12.0.2+10 it's still reproduced.

Ah, creating the root node requires admin privileges. If you're distributing an application, you'll need your application's installer to run as admin and create the root node. Consider if that is what you really want, but it does require your users to run something as admin. This does not justify installing the JDK, as your users wouldn't (or shouldn't) do that, anyway.

> it's up to the user to know what to do with this

Why are you asking your end-users to manually install your development dependencies, though? It's called the J D K for a reason. Ship a linked version of your application.

> Apple requires you to copy this to a very specific, deeply nested, hidden system directory.

This just isn't true - you can run Java from anywhere. It's just a tarball containing the binaries. Un-tar and run the binaries like you would any other program. I never 'install' Java on macOS.

> Why are you asking your end-users to manually install your development dependencies, though?

If you want to run a legacy desktop Java application (without bundled JRE - and yes, there's still plenty of these apps out there), MacOS will actually do the prompting for you.

And it takes you to the commercial JRE download page, which isn't something I'm willing to install. So the only reasonable option I could find as an end-user who wants a non license-encumbered JRE is to install OpenJDK.

> This just isn't true - you can run Java from anywhere. It's just a tarball containing the binaries. Un-tar and run the binaries like you would any other program. I never 'install' Java on macOS.

From the command line, of course that's true.

But if you double click on a .jar file from Finder, does MacOS find your JRE in a random directory? I was pretty sure that it doesn't do that.

I'd argue that you're doing this all at too low-level - users shouldn't have to see JAR files - they don't know what those are.

You should encapsulate the JAR and the JRE in a package.

One should but, as this has never been necessary on macOS, it would be highly unusual.

Java is considered a system-wide framework, even when installed by the user. macOS treats Java applications specially in order to provide them with special macOS-only functionality; for instance, when an application bundle is launched that requires the JRE, the system will open a notification informing the user that a JRE must be installed and provides a helpful link.

There is a further assumption that the version of Java that a user installs will also include a self-updater, ensuring that the user always has the latest version of Java installed to mitigate security issues from using old versions.

The recent modification of Java's licence doesn't seem sufficient impetus to change this behaviour on which all Java applications have depended since Mac OS X first released, one that even continued after Java was deprecated as a built-in installation option.

The reason Java is no longer a system-wide framework, and the assumption that it is has to change, has nothing to do with the recent shift from a semi-free/semi-paid JDK to a 100% free one, and everything to do with the fact that the entire software ecosystem has changed and Java must change with it. Desktop OSes encourage the app store model, and people deploy server applications in containers; neither of these is particularly hospitable to a system-wide runtime. The majority of both developers and end-users prefer a bundled deployment model that fits better with the current software environment (and also gives developer better control over their application's dependencies). If Oracle were to support popular deployment options as well as those that were popular years ago but some people still like, it would come at the expense of other things, like moving the platform forward.

This has been my hell trying to navigate for the past year. As a general rule, anyone who can't commit to updating and testing their software to run on the latest JDK ever 6 months should avoid the Oracle OpenJDK binaries like the plague since support for even LTS versions of Java is dropped 6 months after initial release.

Whether you use LTS versions or not, you must update your JDK every 3 months or so to stay secure, and must perform full regression tests. That we've recently changed the version naming scheme and started giving the 6-monthly updates new integer numbers does not make them major releases. I understand that people are confused because LTS and feature releases perhaps mean something different for Java than for other products, but the probability of an update breaking your app to the point you need to change code isn't much higher for a feature release than for an LTS patch. Updating to feature releases is overall cheaper and easier, it just requires companies to adapt. We realize change is hard and it will take time, but we believe this is the right approach. Those who have made the transition seem to agree.

That's all well and good for software developed in house by a full time development team that gets deployed to a single known environment, but that's only one way that the JDK gets used. If you provide software to customers to deploy in their own environments without direct control over updates, or if you have maintenance mode line of business software that you just want to keep patched this becomes a much bigger burden. Oracle also hasn't really been giving the time for these changes to be adopted either when the support for even LTS JDK builds is dropped at the same time the next stable major version is released. I realize that Oracle's answer is "and that's when you should pay us for support", but for anyone who wants to continue to use Java (or the JDK) in the "free" way its been historically, it's so much safer form a business perspective to use a JDK provider that has better support commitments to their free versions. Other than the fact that it's the default served by *.jdk.net that people are used to, I don't see why you would choose the Oracle OpenJDK over another provider.

Free support for JDK 8 ended after an average of 5 years and a notice of one year. Moreover, early access and then public availability JDK 9 builds were avaialble for a year and a half before end of public support. This is at least as much time as any previous version. Add to that the fact that the current free perpetual support is cheaper and easier than ever (although it does require a bit of getting used to), and the claim that people did not have enough time to adjust sounds tenuous.

In addition, Oracle has completely open-sourced the JDK, for the first time ever, and as we had done several times before, we transferred ownership of old JDK versions to Red Hat. Feel free to use whatever OpenJDK distribution you find suitable to your needs, but keep in mind that 90% of the work on OpenJDK is done by Oracle.

Finally, it is incorrect to say that support is dropped the next time the major version is shipped as Java 9 was the last major release ever. "Dropping support" for the semi-annual release as soon as the next one is released has been the practice for at least the past 7 years (e.g. there were no further updates to 8 once 8u20 was released). What has changed is that the semi-annual releases get an integer number. This certainly confuses people who don't realize that what would have been called 9u20 was renamed 10 and so on, and that cheaper upgrades are now easier and cheaper than ever before. So I agree communication could have been better (we're working on that), but I disagree with your characterization.

To summarize, free perpetual support is easier than ever, there was plenty of time for people to adjust, and open sourcing of the JDK has opened up the field for other distributions for different support options. All in all, things are cheaper, freer, and you have more options than ever. Yes, it seems that people have not yet internalized the meaning of the new feature releases (they are not major releases, but much closer to the old "limited update" releases), as well as the meaning of LTS (which is only recommended if you have a good reason not to use the current JDK).

We've been using it on Docker and love it.

Please add an option with JavaFX bundled.

JavaFX included in builds from here (branded "Zulu FX"): https://www.azul.com/downloads/zulu-community/

(select JRE FX or JDK FX from the dropdown I guess - they've changed the download page recently)

May be it's just me, but on Mac the process is rather convoluted, and is certainly not optimized for end user.

We hear you - it's being worked on for 11+. 8 we're not so sure bout as the OpenJFX version there is unmaintained

Thank you!

What are the rules around distributing OpenJDK as part of a commercial software/hardware product?

The licensing section should answer that question:

https://adoptopenjdk.net/about.html

Notable omissions: any BSD platform.

We're chatting to the FreeBSD and OpenBSD folks about this.

Does the Amazon JDK binary distribution compete with this?

Technically? Yes, Correto is it's own separate distribution that Amazon manages porting upstream changes into. Same as how Azul's Zulu is a "competitor" as well.

Practically speaking, it shouldn't matter as they all pass the Java TCK.

1. AdoptOpenJDK does not run the TCK.

2. Corretto and Zulu each have their own patch set. Corretto backports a couple of G1 fixes and Zulu backports Flight Recorder and TLS 1.3.

1. Ooh that's good to be aware of...

Although no TCK we do run > 100,000 open tests, including many popular open-source libraries, frameworks and languages. We're very comfortable standing behind the quality of these binaries :-).

Please add an option for JRE in the browser - JRE compiled to JavaScript or WASM (like CheerpJ or TeaVM).

Don't see the point in this unless someone were to write a HotSpot backend that generated WASM.

Seems maybe strange to run a JIT on a JIT. There are some smaller JVMs that likely wouldn't need to be that different, but running HotSpot on WASM, particularly in the browser, seems strange.

Why not compile your classes to WASM instead?

Java would work ok with AOT compilation. The major thing missing for running Java and many other languages on WASM would be garbage collection.

https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

i wish there were still 32 bit JDKs for Java11+

There is for Windows and ARM32 - we're looking at Linux x86 (32bit) but not 100% sure we'll be able to deliver that.

It should be noted that AdoptOpenJDK does not run the TCK against these binaries so they can not be called a compatible Java implementation.

The TCK is not open, it isn't governed by a standards body, the TCL is completely in Oracle's control.

If Java is to evolve as an open platform, it needs to break free from the TCK that disallowed Apache Harmony to exist.

We don't need it and an independent TCK could be developed.

Yet any other OpenJDK distribution from Alibaba, Amazon, Azul, BellSoft, RedHat, SAP (I probably forgot some) all run the TCK. All except AdoptOpenJDK. And whenever you bring that up the only response is ranting about the TCK.

No ranting from us :-). We've not been granted access to the TCK and we continue to hold an open dialogue with Oracle on this. We hope to get this resolved down the line!

Reply on news.ycombinator.com