To build and run Java applications, a Java Compiler, Java Runtime Libraries, and a Virtual Machine are required that implement the Java Platform, Standard Edition (“Java SE”) specification.
The OpenJDK is the open source reference implementation of the Java SE Specification, but it is only the source code. Binary distributions are provided by different vendors for a number of supported platforms. These distributions differ in licenses, commercial support, supported platforms, and update frequency.
This site gives independent, yet opinionated recommendations.
✅ Recommendation: Use Adoptium Eclipse Temurin 21 and ensure that your local version matches the CI and production version.
Under the current JDK release model, a new feature release with a new major version number is planned every six months, in March and September. Additionally, there are quarterly bug fix updates.
Every two years, the September release will be a Long-Term-Support (LTS) release, which gets updates for at least three years.
|JDK Version||Type||Release Date||Highlights||Recommendation|
|8||LTS||03/2014||Lambdas||Last LTS version under previous release model. Free updates by Oracle ended, but still maintained by others. Upgrade to a 11 or 17 within the next months!|
|9||Feature||09/2017||Modules||New release model was introduced. EOL. Upgrade to 17 or 21 now!|
|10||Feature||03/2018||var||EOL. Upgrade to 17 or 21 now!|
|11||LTS||09/2018||New HTTP Client||Upgrade to 21 now!|
|12||Feature||03/2019||EOL. Upgrade to 21 now!|
|13||Feature||09/2019||EOL. Upgrade to 21 now!|
|14||Feature||03/2020||Switch expressions||EOL. Upgrade to 21 now!|
|15||Feature||09/2020||Text blocks||EOL. Upgrade to 21 now!|
|16||Feature||03/2021||Records||EOL. Upgrade to 21 now!|
|17||LTS||09/2021||Sealed Classes||Supported LTS verison. Consider upgrading to 21 in the next months.|
|18||Feature||03/2022||UTF-8 by Default||EOL. Upgrade to 21 now!|
|19||Feature||09/2022||Preview and incubator features, only||EOL. Upgrade to 21 now!|
|20||Feature||03/2023||Preview and incubator features, only||EOL. Upgrade to 21 now!|
|21||LTS||09/2023||Pattern Matching, Virtual Threads||Current LTS version.|
You have to decide if you want to stick with the latest LTS version, or if you go with the latest feature release and upgrade every six months. Both options are okay, but if you’re uncertain, stick with the latest LTS version.
The OpenJDK project itself is managed on openjdk.java.net where you can find specifications, source code, and mailing lists, but there are no builds that you can download. You need to choose a distribution.
Oracle provides OpenJDK builds for Linux, macOS and windows in a compressed archive format.
These builds will only be updated for a 6-month period. Updates and security patches will not be available after this short period. This also applies for LTS versions! e.g., the latest OpenJDK 11 build was 11.0.2+9 while the current OpenJDK version is 11.0.12+7.
⛔️ Recommendation: Do not use OpenJDK builds by Oracle, particularly if you plan to stick with LTS versions.
Oracle provides a commercial version of the OpenJDK, which are based on the exactly same sources of the OpenJDK: The Oracle Java SE Development Kit (JDK). Oracle provides updates regular updates and security patches for these builds.
The main issue with these builds is Oracle’s licensing policy:
Until version 10, builds were published under the Oracle Binary Code License Agreement, which effectively allowed the builds to be used for commercial projects.
With version 11 to version 16 builds were published under the Oracle Technology Network License Agreement for Oracle Java SE, which require a fee-based license for usage in production. This is why many new distributions of the OpenJDK have emerged.
Version 17 is published under the Oracle No-Fee Terms and Conditions (NFTC), which allows the usage of the builds for running internal business operations. Unfortunately, the phrase “internal business operations,” is not defined and is a very vague phrase (e.g. is a public-facing website running internal business operations?).
Also, based on this volatile licensing history, it is not predictable, how future version will be licensed.
⛔️ Recommendation: Do not use Oracle Java SE Development Kit (JDK) before consulting your lawyer.
Eclipse Adoptium is a top-level project under the Eclipse Foundation, which provides resources and a professional governance model for open source software. The Adoptium Working Group consists of major companies and organizations that have a strategic interest in the Java technology, including Red Hat, IBM, Microsoft, Azul, and the iJUG. The former AdoptOpenJDK project has moved to Eclipse Adoptium.
The Adoptium OpenJDK builds are called Eclipse Temurin to distinguish the project from the builds.
Eclipse Temurin builds are high-quality, vendor-neutral, and TCK-tested under a permissive license.
Adoptium states, it will continue to build binaries for LTS releases as long as the corresponding upstream source is actively maintained.
✅ Recommendation: Adoptium Eclipse Temurin OpenJDK builds are highly recommended.
The AdoptOpenJDK project was the predecessor of Eclipse Adoptium and provided high-quality OpenJDK builds, both for the default HotSpot and the OpenJ9 virtual machine.
The website and older releases are kept online to access archived releases.
⛔️ Recommendation: Do not use AdoptOpenJDK anymore. Use Adoptium Eclipse Temurin instead.
Azul Systems, Inc., has specialized in professional Java technologies and commercial support for JDK. Azul has a high-industry reputation and is engaged in various working groups to evolve the Java platform.
Azul provides open source OpenJDK builds called Azul Zulu for many operating systems and architectures. Additionally, Azul provides builds for special requirements, such as stripped down JREs and builds including OpenJFX.
A downside of these builds is the dependency to a single company, that may suddenly change its license or update policies.
✅ Recommendation: Azul Zulu Builds of OpenJDK are a good choice.
Azul Zing is a commercial JDK, currently marketed as Azul Platform Prime. It requires a commercial contract with Azul Systems for production use.
Zing is OpenJDK-based, and adds the patented “C4 Pauseless Garbage Collector”, the “Falcon JIT Compiler” (that optimizes for throughput at the cost of higher CPU usage and longer start-up and warm-up times), and some features to speed up compiler warm-up time (to mitigate the Falcon JIT Compiler’s slower warm-up times by profiling and storing optimizations of training runs in files).
Azul Zing has some use cases in financial trading applications, where GC pauses are a problem. Apart from that, the regular OpenJDK contains the free low-pause time GCs Shenandoah and ZGC that may be an alternative.
⚠️ Recommendation: Consider Azul Zing / Azul Platform Prime when GC pause times are a problem. Do not use it in production without a license.
Similar to Azul, BellSoft has specialized in professional Java technologies and commercial support for JDK. Also, BellSoft has a high industry reputation and is engaged in various working groups to evolve the Java platform.
BellSoft provides open source OpenJDK builds called Liberica JDK for pretty much all operating systems and architectures.
The popular Spring Boot framework chose Liberica JDK as runtime for their buildpack.
A downside of these builds is the dependency to a single company, that may suddenly change its license or update policies.
✅ Recommendation: BellSoft Liberica JDK builds are a good choice.
IBM developed its own version of the Java Virtual Machine, called J9 and it was open-sourced as Eclipse OpenJ9. It is an alternative to the default HotSpot Java Virtual Machine, but it has never gained much popularity.
IBM now provides builds called Semeru Runtime based on the Eclipse OpenJ9 Java Virtual Machine and some OpenJDK class libraries. OpenJ9 has a low memory footprint and starts fast with shared classes, but lower throughput compared to Hotspot Virtual Machine.
⚠️ Recommendation: Use IBM Semeru Runtime only if you know that you need the OpenJ9 Virtual Machine.
Since Oracle changed the support and license policy for its OpenJDK builds, major cloud providers decided to establish their own managed OpenJDK builds and providing long-term updates. Apparently, this is to avoid risks, especially lawsuits against Oracle.
In 2018, AWS published Corretto, yet another OpenJDK build.
AWS includes back ports of bug fixes from newer OpenJDK versions and claims that they would add patches that might not yet be integrated in the OpenJDK project. Amazon has implemented an alternative crypto provider that has been optimized for their services. It is planned to be used as the default crypto implementation in Corretto.
Amazon provides releases for major development platforms and an optimized version for its own Amazon Linux 2.
✅ Recommendation: Corretto builds are a good choice, particularly if you run Java applications directly on Amazon Linux 2 in AWS.
In 2021, Microsoft published Microsoft Build of OpenJDK, yet another OpenJDK build.
Microsoft may include back ports of bug fixes from newer OpenJDK versions and claims that they would add patches that might not yet be integrated in the OpenJDK project.
Microsoft provides releases for major development platforms.
⚠️ Recommendation: Use Microsoft Build of OpenJDK, only if you run Java applications directly on Azure. There are more established options available.
Alibaba provides an OpenJDK build which includes back ports and some extra features.
⛔️ Recommendation: Do not use Alibaba Dragonwell, unless you are forced by your government.
SapMachine is yet another OpenJDK Build, maintained by SAP.
⚠️ Recommendation: Use SapMachine only if you are running Java applications on SAP servers. There are more established options available.
Red Hat provides OpenJDK builds for LTS versions.
⚠️ Recommendation: Use Red Hat OpenJDK only if you are running Java applications directly on Red Hat Enterprise Linux. There are more established options available.
The project is discontinued. The ojdkbuild project had the goal of providing Windows x86_64 binaries of OpenJDK that are as close in behaviour to Linux OpenJDK packages as possible, e.g. by using system libraries instead of packaged versions of zlib or OpenSSL. It used the packages included in CentOS. A use case for these builds was to develop Java software on Windows machines and deploy them to Linux servers in production.
⛔️ Recommendation: Do not use ojdkbuild, as the project is discontinued.
GraalVM is a fully compliant JDK, but much different from all the others builds.
GraalVM was developed by Oracle. It is based on the OpenJDK but includes a new high-performance compiler and a new polyglot virtual machine (can execute code written in different programming languages). It is also possible to create platform-specific native executable that are highly optimized and start extremely fast.
🤷 Please share your experiences with GraalVM in production, so that we can elaborate a validated recommendation.
The official support for macOS/AArch64 was implemented with JEP 391 in the OpenJDK 17 release.
macOS x64 builds run stable with Rosetta 2, but there is a significant performance drop due to emulation. People that develop on an Apple Silicon Mac (like me) should install a native macOS AArch64 (aka ARM 64) build of the JDK.
To list available JDKs, type
sdk list java
and install a specific version:
sdk install 18.104.22.168-tem
Validate by checking the version:
which java `which java` --version
On Linux, you might also try
Some distributions provide a JDK (Java Development Kit) and a JRE (Java Runtime Environment) build. A JDK includes everything to compile, package and run Java applications, while a JRE only includes the binaries and libraries to run Java applications. The JRE is a stripped down version of the JDK, and is smaller in terms of megabytes.
If size matters for you, consider creating your own stripped-down runtime using jlink.
For local development, you need a JDK. In production you only need a runtime environment, but it is quite common to use the JDK, too.
Java EE (Java Platform, Enterprise Edition) was renamed to Jakarta EE. It is a specification to build server app and frontends. In terms of scope, Jakarta EE can be compared with more modern frameworks like Spring Boot, Micronaut, and Quarkus, but Jakarta EE feels more complicated.
⚠️ Recommendation: Do not start new projects based on Jakarta EE. Most people use Spring Boot, which is a good choice. Consider Quarkus, if you have a strong Java EE background. Consider Micronaut, if you like Groovy and Grails.
This site is maintained by Jochen Christ. Any recommendations or opinions represented on this site are personal and based on long-term professional experience. The author is not associated with any of the organizations stated here.
Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.