There is a great answer here... https://stackoverflow.com/questions/52524112/how-do-i-instal...
brew install java (12)
brew install java11
In your .bashrc:
export JDK_HOME=`/usr/libexec/java_home -v 12` # v9+ change to the version you installed
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.
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.
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.
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.
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.
Implying applications always receive continued development...
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.
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.
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.
> 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 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.
* 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.
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.
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.
You should encapsulate the JAR and the JRE in a package.
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.
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).
(select JRE FX or JDK FX from the dropdown I guess - they've changed the download page recently)
Practically speaking, it shouldn't matter as they all pass the Java 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.
Why not compile your classes to WASM instead?
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.