Tuesday 28 August 2018

Java is still available at zero-cost

The Java ecosystem has always been built on a high quality $free (zero-cost) JDK available from Oracle, and previously Sun. This is as true today as it always has been - but the new six-monthly release cycle does mean some big changes are happening.

Six-monthly releases

Java now has a release every six months, something which greatly impacts how each version is supported. By support, I mean the provision of update releases with security patches and important bug fixes.

Up to and including Java 8, $free security updates were provided for many years. Certainly up to and beyond the launch of the next version. With Java 9 and the six-monthly release cycle, this $free support is now much more tightly controlled.

In fact, Oracle will not be providing $free long-term support (LTS) for any single Java version at all from Java 11 onwards.

VersionRelease dateEnd of $free updates from Oracle
Java 8March 2014January 2019 (for commercial use)
Java 9Sept 2017March 2018
Java 10March 2018Sept 2018
Java 11Sept 2018March 2019 (might be extended, see below)
Java 12March 2019Sept 2019

The idea here is simple. Oracle wants to focus its energy on moving Java forward with the cost of long-term support directly paid for by customers (instead of giving it away for $free). To do this, they need developers to continually upgrade their version of Java, moving version every six months (and picking up the patch releases in-between). Of course, for most development shops, such rapid upgrade is not feasible. But Java is now developed as OpenJDK, which means that Oracle's support dates are not the only ones to consider.


A key point to grasp is that most JDK builds in the world are based on the open source OpenJDK project. The Oracle JDK is merely one of many builds that are based on the OpenJDK codebase. While it used to be the case that Oracle had additional extras in their JDK, as of Java 11 this is no longer the case.

Many other vendors also provide builds based on the OpenJDK codebase. These builds may have additional branding and/or additional non-core functionality. Most of these vendors also contribute back to the upstream OpenJDK project, including the security patches.

The impact is that the JDK you use should now be a choice you actively make, not passively accept. How fast can you get security patches? How long will it be supported? Do you need to be able to apply contractual pressure to a vendor to help with any issues?

In addition, there are two main ways that the JDK is obtained. The first is an update mechanism buit into the operating system (eg. *nix). The second is to visit a URL and download a binary (eg. Windows).

To examine this further, lets look at Java 8 and Java 11 separately.

Staying on Java 8

If you want to stay on Java 8 after January 2019, here are the choices as I see them:

1) Don't care about security.

It is entirely possible to remain on the last $free release forever. Just don't complain when hackers destroy your company.

2) Rely on Operating System updates.

On *nix platforms, you may well obtain your JDK via the operating system (eg. Red Hat, Debian, Fedora, Arch, etc.). And as such, updates to the JDK are delivered via the operating system vendor. This is where Red Hat's participation is key - they promise Java 8 updates until June 2023 in Red Hat Enterprise Linux - but they also have an "upstream first" policy, meaning they prefer to push fixes back to the "upstream" OpenJDK project. Whether you get security patches to the JDK or not will depend on your operating system vendor, and whether they need you to pay for those updates.

3) Pay for support.

A number of companies, including Azul, IBM, Oracle and Red Hat, offer ongoing support for Java. By paying them, you get access to the stream of security patches and update releases with certain guarantees (as opposed to volunteer-led approaches). If you have cash, maybe it is fair and reasonable to pay for Java?

4) Use the non-commercial build in a commercial setting.

Oracle will provide builds of Java 8 for non-commercial use until December 2020, so you could use those. But you don't want Oracle's software licensing teams chasing you, do you?

5) Build OpenJDK yourself.

The stream of security patches * is published to a public Mercurial repository under the GPL license. As such, it is perfectly possible to build OpenJDK yourself by keeping track of commits to that repository. I suspect this not a very realistic choice for most companies.

6) Use the builds from Adoptium AdoptOpenJDK.

Update 2021-11-04: AdoptOpenJDK is now Adoptium. The links below have not been updated as there is not a matching page in all cases.

The community team at AdoptOpenJDK has been busy over the past few years creating a build farm and testing rig. As such, they are now able to take the stream of security patches * and turn them into releases, just like you would get from the commercial offerings. They also intend to run the Java TCK (testing compatibility kit) to allow these builds to be fully certified as being compatible with the Java SE specification. Their plan is to produce Java 8 builds until September 2023 or later (two years after Java 17 comes out). Obviously, you don't get a warranty or genuine support - its a community build farm project. But for most users that want to use Java 8 without paying, this is likely the best choice.

Note that Azul also offers $free OpenJDK release builds under the name Zulu. A key advantage of Azul's offering is that you can pay for support later if you need it without changing your JDK.

* The last two options assume that a group actually will step forward and take over the "JDK 8 updates" OpenJDK project once Oracle stop. While the exact project details are not yet confirmed, this IBM statement indicates real backing for the approach:

Recognizing the impact that the release cycle changes will have with Java developers, IBM will partner with other members of the OpenJDK community to continue to update an OpenJDK Java 8 stream with security patches and critical bug fixes. We intend to keep the current LTS version secure and high quality for 4 years. This timescale bridges the gap between LTS versions with 1 year to allow for a migration period. IBM has also invested in an open build and test project (AdoptOpenJDK.net) along with many partners and Java leaders to provide community binaries across commonly used platforms of OpenJDK with Hotspot and OpenJDK with Eclipse OpenJ9. These community binaries are TCK (Java SE specification) compliance tested and ready for developers to download and use in production.
IBM statement

And here is further indication of Red Hat's support for the June 2023 date, based on their "upstream first" policy.

> Red Hat has said it may step forward to be the maintainer for JDK 11 - might it also > step forward to be the maintainer for JDK 8?
> How long will JDK 8 be maintained?
June 2023 is right for JDK 8, but I wouldn't be surprised if it goes on beyond that.
Andrew Haley, Red Hat

And finally, here is the official Oracle view on that transition.

Note that the process around security issues will be managed by the newly formed vulnerability group (which formally codifies what was happening anyway).

Staying on Java 9 or Java 10


No-one wants to provide builds or support for Java 9 or Java 10. And anyway, there is no good reason not to upgrade to Java 11 in my opinion.

(Actually, Azul are providing medium-term support for Java 9, if you really need it.)

Staying on Java 11

It is a brave new world and not 100% clear, but this is how it looks like things will happen.

Firstly, it is not clear that there will be an Oracle JDK that is $free to download. Despite my best attempts, I could not get 100% clarity on this point. However, this tweet and other sources indicate that it will be accessible for development purposes, just not for use in production (which is a bit of a trap for the unwary). But in reality, it is now irrelevant as to whether Oracle JDK is $free to download or not.

Now that Java 11 is released, we can see that Oracle JDK can be downloaded for $free. However, the license has changed, explicitly ruling out use in a production environment (without paying). Given that Oracle JDK has been the main JDK in use for 23 years, this is a huge trap for the unwary.

But this is not actually a problem, because Oracle JDK is no longer that important. That is because from Java 11, developers can treat Oracle JDK and OpenJDK as being equivalent. (See here for the detailed differences.) It is no longer appropriate or correct to consider the OpenJDK build to be secondary or less important. In fact, the most important build is now the OpenJDK one.

To be more specific, as of the release date, Java 11 developers should consider using AdoptOpenJDK or jdk.java.net to obtain a binary download, not any page on oracle.com.

So, for how long will Oracle provide security patches to Java 11?

Again, the answer to this is not 100% clear:

> What will Java 11 get from Oracle?
At least six months of free, GPL-licensed updates with binaries at https://jdk.java.net.
(I say “at least” because that’s the current plan. The plan could change, to a longer time period, if the situation warrants.)
Mark Reinhold, Oracle

Clearly, six months of security updates is not long enough to treat Java 11 as a "long term support" (LTS) release. The promise of the period being potentially longer doesn't really help, as companies need longer timelines and more certainty. So the working assumption should be that Java 11 has just 6 months of releases containing security patches from Oracle.

At this point, things move into the realms of probabilities. In all likelihood, when Oracle steps down from managing the "JDK 11 updates" project at OpenJDK (the one containing the security patches), someone else will take over. Exactly as with Java 8, discussed above. This has happened before with Java 6 and 7. And the evidence is that it will happen for Java 11 too:

OpenJDK is a community project. It's up to the community to support it. In practice this means that a group of organizations and individuals will maintain each OpenJDK LTS release for some period (TBA for 11, but it's sure to be a *lot* longer than six months.) I am certain that there will be a jdk11u project, and it will be properly and professionally run. I think it's likely that I'll be leading the project, but someone else may be chosen.
Andrew Haley, Red Hat

See also this Red Hat blog on the topic.

That covers the repository containing the security patches. (Red Hat have an excellent record in maintaining old releases of OpenJDK for the wider community.) But there is still the question of producing actual releases to download that have been certified as passing the Java SE testing TCK.

This is where the AdoptOpenJDK build farm is critical:

As part of the discussions Andrew mentioned, AdoptOpenJDK offered to build, test and make available OpenJDK LTS binaries for the major (and several minor) platforms. This isn't yet set in concrete but folks broadly thought that was a good idea. So the challenge of having a build and test farm for this joint effort is solved.
Martijn Verburg, AdoptOpenJDK

And AdoptOpenJDK are currently planning to do create releases until September 2022, one year after Java 17 comes out.

If people do what they say they will, then we can therefore conclude that it will be possible to use Java 11 for 4 years from release, with security patches, for $free (zero-cost). (I would imagine that if volunteers came forward, the September 2022 date could be moved even further into the future.)

Of course, only you and your company can decide if it is right and proper to use Java without giving back to the ecosystem. It could be argued that it is more ethical to either pay for support, or assist either the AdoptOpenJDK or "JDK 11 updates" OpenJDK project.

This is therefore the updated table of $free updates:

VersionRelease dateEnd of Oracle $free updatesEnd of OpenJDK-based $free updates
Java 8March 2014January 2019June 2023 (or later)
Java 9Sept 2017March 2018N/A
Java 10March 2018Sept 2018N/A
Java 11Sept 2018March 2019 (or later)September 2022 (or later)
Java 12March 2019Sept 2019N/A

(June 2023 is the date Red Hat has provided for the end of JDK 8 security patches, September 2022 is the date AdoptOpenJDK have provided - one year after the expected release of the next LTS (long-term support) version, Java 17).


The OpenJDK builds by Oracle at jdk.java.net only cover three platforms. But this doesn't mean that they are the only platforms OpenJDK runs on. For example, AdoptOpenJDK provides Java 8 builds on 9 platforms with Hotspot (including ARM, Windows 32-bit and Solaris) and more platforms with OpenJ9.


All the pieces are in place for Java 11 to be maintained as a long-term support release. However, unlike Java 6, 7 and 8, Oracle will not be leading the long-term support effort. In all likelihood, Red Hat will take over this task - they have said publicly that they would like to.

For the first 6 months of Java 11's life, Oracle will be providing GPL+CE licensed $free zero-cost downloads at jdk.java.net with security patches.

To get GPL+CE licensed $free zero-cost update releases of Java 11 after the first six months, you are likely to need to obtain them from a different URL and a different build team. Currently, my view is that your package manager or Adoptium is the best place to look for those builds.

Feel free to comment if I've missed something obvious.


  1. Thank you for this useful, important info. Btw, minor typo: 'Any anyway'

  2. It's absolutely an indictment of Oracle's stewardship of Java that it takes a blog post (however excellent) from a non-employee (however central a Java community member) to coherently explain their plan for the future of Java. Customers, vendors, and coworkers are getting mixed messages from news sources, and it's causing a whole bunch of uncertainty: the one thing you absolutely do not want in an enterprise software platform.

  3. Will critical Java vulnerabilities in 11 be fixed by RedHat or AOJDK even long after Oracle has abandoned that version? I think this is where the probabilities drop significantly. It will be interesting to see what happens.

    1. By the OpenJDK vulnerability group.

  4. One option you overlooked is to use the JDK provided by your OS vendor. For example, if you're running on RHEL RedHat says they'll support Java 8 through June 2023 (https://access.redhat.com/articles/1299013). I imagine CentOS will receive these OpenJDK updates as well.

    1. I included "pay for support", and you probably pay for RHEL...

  5. I'd like to see Redhat/CentOS/AWS/Canonical use the AdoptOpenJDK builds in their upstream repos. Is there any reason to believe they would or would not?

    1. Because binary compatibility precludes it and there are trust and responsibility issues when rebundling others software.

      Best plan is not to do it. Also monocultures are bad.

    2. There is no chance that we will use the AdoptOpenJDK builds because we tweak our builds to use system libraries rather than bundled libraries and we make a few other distro-specific patches. Also, as a matter of policy, our distros are built from source.

    3. How can we tell that a Linux distro build has or has not passed the TCK or that the version arvertised by the OS is the right version/patch version. I know of at least one screw up from at least one major distro for that. I've never been able to find the provenance of an OpenJDK package provided by a distro. I have no idea what flags we're used to build it. Each distro needs to make this clear. I see Amazon, Canonical, RedHat as signatories for the JCK, but where can I tell if a specific package provided from those distros package repositories has actually been run against or passed the JCK?

    4. You have to ask. I can tell you that Red Hat packages pass the JCK, and I'm pretty sure that Azul's do too.

    5. Will the JDK packages in Fedora also be built from the tweaked and patched sources used in RHEL? Or are they some more stock OpenJDK?

  6. Thanks for the info. I'm still confused though. Does Oracle's new license policy only apply to the JDK, or also apply to the JRE? Do I have to pay for the Oracle 11 JRE in production or only when using the JDK?

    1. If you want zero-cost, avoid Oracle JDK/JRE.

    2. A lot of IT support people are wondering the same thing. It sort of counts as commercial use if I'm using the JRE as part of a job to access business sites and apps, but also not the same as commercially developing Java apps with the JDK. But even if we use the JRE 8 updates until they're done, it looks like eventually we'll have to move to a JRE based on Java 11. But from who I'm not sure.

    3. Oracle's new license policies apply to both the JDK and the JRE. Java 9.x and later eliminate the distinction. See JEP 220, http://openjdk.java.net/jeps/220. It says: "The present distinction between JRE and JDK images is purely historical, a consequence of an implementation decision made late in the development of the JDK 1.2 release and never revisited. The new image structure eliminates this distinction: A JDK image is simply a run-time image that happens to contain the full set of development tools and other items historically found in the JDK."

  7. I certainly hope http://jdk.java.net will install a certificate to create a secure link for downloads

    1. That's not a bad idea. jdk.java.net is not an OpenJDK site, though, and we'd have to thgink about how to handle the signing keys. It's possible that several organizations will be doing the builds for various platforms.

  8. The Oracle vs Google proves the contrary though.

  9. Thank you for the explanation! I was quite lost after away from java for a while. This article clarify my confusion over the java versions.

  10. Excellent article providing a good understanding of the situation. Thank you.

  11. AdoptOpenJDK build for myself, Zulu if I am to recommend for others (too bad AdoptOpenJDK doesn't serve windows installer format yet). I'm just glad that this change means one less reason to ever visit Oracle website.

  12. Thank you for the very comprehensive article. I finally feel I have handle on the changes to expect.

  13. Very good information. Thank you.

  14. Thanks for sharing this information. With regards to Oracle JDK 8 you mention:
    "Oracle will provide builds of Java 8 for non-commercial use until December 2019"

    Shouldn't it be December 2020, according to Oracles JSE roadmap:


  15. Thank for these clear explanations.

    What about the JDK documentation? The API javadoc link on http://jdk.java.net/11/ points to Oracle web site. Then when you try to download the JDK doc on https://www.oracle.com/technetwork/java/javase/documentation/jdk11-doc-downloads-5097203.html, you have to accept a license which states basically that you can use the program (including documentation) only for development purposes.

    Is there an unencumbered way to get the API documentation?

    1. Part bug, part coming soon. See https://twitter.com/DonaldOJDK/status/1045790387736989696

    2. I forgot about making the javadoc from source! Of course it's the good way to get the doc until they publish the zip under a free license. Thank you again!

  16. I'm an Android developer and I use android studio as IDE which requires me to setup jdk..so will I or developers of the IDE will take subscription plan of Oracle jdk?

    1. No. Just change your JDK to an OpenJDK build such as http://jdk.java.net (uninstall Oracle JDK). Your IDE will work just fine with OpenJDK.

  17. I am still confused , OpenJdk will have any LTS release or not.

    1. Yes, you can get 4+ years of LTS on OpenJDK for free thanks to Red Hat and others providing the security patches. Just use an OpenJDK build, such as from your package manager, AdoptOpenJDK or Azul Zulu.

  18. Oracle will designate a release, every three years, as a Long-Term-Support (LTS) release. Java SE 11 (18.9 LTS) is an LTS release with the Premiere Support until September 2023.

  19. There is an error in the text:
    Staying on Java 8
    "Their plan is to produce Java 8 builds until September 2022, one year after Java 17 comes out."

    according to https://adoptopenjdk.net/support.html
    it should read
    "until September 2023"


  20. Java version 10 and 11 (bug fixing) out you can find more at Java versions History and https://en.wikipedia.org/wiki/Java_version_history

  21. Best explanation I have seen so far.

  22. Using Open JDK your app must be published (if you're going to) on GPL license. Am I correct?

    1. No. The license of OpenJDK is GPL+CE where the "+CE" part means "with Classpath exception". While I am not a lawyer, the effect of "+CE" is that code using the JDK is not impacted by the GPL's normal rules wrt publishing: https://softwareengineering.stackexchange.com/a/326325/117391

  23. Sekhar Kutikuppala19 November 2018 at 23:32

    Another option is AWS variant of OpenJDK. AWS launched a no-cost, multiplatform, production-ready distribution of OpenJDK.


  24. Best explanation so far. Thank you so much for this. For some reason I have a feeling something similar will happen to MySQL anytime soon...

  25. What will happen to the personal user after 2020? Is the developer responsible to license their customer or the customer will need to purchase a liense to get an update? thanks.

  26. I've been trying to figure out for MONTHS what this change means for business computers that simply need to have Java installed because they need it for some website they have to go to. No Java development being done by the business, just simple access to a web page that uses Java. Is that considered "business use", thus we must pay to have Java on any PC that needs to use such a page? Or is that "personal use"? The warning when a Java update sure makes it seem like we are expected to pay, but what we are actually paying for, or even HOW we would do that, is clear as mud.

    1. This page was updated to classify three use types of Java. You use case sounds like "business use" to me, so you need to switch your users to OpenJDK or pay Oracle. Lucky you. https://www.oracle.com/technetwork/java/java-se-support-roadmap.html

  27. This is a noob, small fry question. I was planning to learn Clojure. With the goal to be able to build and sell software. Does this mean that I must rethink? Are Common-Lisp environments $free?

  28. Regarding your point on AdoptOpenJDK being TCKed and hence Java SE compatible , their support page seems to be not matching this view https://adoptopenjdk.net/support.html. As it says they are still in agreement with Oracle to use TCK/JCK as per Oracle License: OCTLA.
    They are verifying quality as per their/community owned test for build.

    1. There is a dispute between AdoptOpenJDK and Oracle about the TCK at present. I'm not party to the details.

  29. Your explanation is very good, thank you very much for this.

    I will start to test my current developments with OpenJDK. Currently I use Oracle JDK8, I will start testing my code with OpenJDK8, should I consider modifying something in my code or should it work without problems?

  30. AdoptOpenJDK Linux x64 build https://adoptopenjdk.net/releases.html#x64_linux is not compatible with RHEL5/CentOS5 because of using ABI loader https://github.com/AdoptOpenJDK/openjdk-build/issues/698 (libjvm.so: ELF file OS ABI invalid)

  31. Ok the important question for me is, which distribution do I download.
    We're running Ubuntu not RHEL. Currently Red Hat are not publishing a binary distribution of their OpenJDK for other Linux Distros.

    If on Ubuntu 16.04 (docker image) I do :
    add-apt-repository ppa:openjdk-r/ppa
    apt-get install openjdk-11-jdk-headless

    Who's distro am I getting?

  32. This comment has been removed by a blog administrator.

  33. This comment has been removed by a blog administrator.

  34. This comment has been removed by a blog administrator.

  35. This comment has been removed by a blog administrator.

  36. This comment has been removed by a blog administrator.


Please be aware that by commenting you provide consent to associate your selected profile with your comment. Long comments or those with excessive links may be deleted by Blogger (not me!). All spam will be deleted.