There has been a lot of confusion lately about Java and its available SDKs (Software Development Kits). You might’ve heard the Java SDK called the JDK. They’re one and the same. Java SE (Standard Edition) is a specification that’s governed by the JCP (Java Community Process). This process decides what goes into (or gets removed from the JDK). Anyone can implement the Java specification. If they pass the TCK (Test Compatibility Kit), they’re considered a viable JDK.
Confusion around the Java SDK started because of two events:
Here’s a quick summary of Oracle’s changes:
To make matters more contentious, Oracle will end public updates for Java 8 this month! This isn’t out of the ordinary, it regularly does this for major Java versions after five years of public availability. Related: public updates for Java 11 will end this March when Java 12 is released.
This largely has to do with support contracts. I don’t know about you, but I’ve never paid for a Java support contract in my career. Granted, I’ve spent most of my developing days as an independent consultant. I’m willing to bet that most of you haven’t paid for Java support either. My guess is the people who pay for Java support are in charge of companies that built their business on Java and can’t migrate to the latest version. They need support and security fixes for older versions because they can’t upgrade.
When Oracle changed its support model for Java, there was a low roar in the community that Java was no longer free. To help clarify things, the Java Champions group created an open letter clarifying the available support options. You can read more in InfoQ’s Java Community Leaders Clarify Platform Support Options: "Java Is Still Free".
Currently, the only source code for the JDK is in the Open JDK project. You can check out the source code for OpenJDK and build it yourself if you like. However, it’s not considered "Java SE compatible" unless it passes the TCK. Also, you cannot call it "Java SE" without getting a license from Oracle.
There are many Java SDK options besides Oracle’s. Let’s take a look at the main ones and when you might want to use them. I’ve listed them below in alphabetical order.
Hat tip to Stephen Colebourne and his Time to look beyond Oracle’s JDK blog post for much of this information.
AdoptOpenJDK is a community and code that builds free OpenJDK binaries. They’re published to adoptopenjdk.net. Binaries are published for five years after the version’s initial release. Builds are available for OpenJ9 (IBM’s JVM) and HotSpot.
What is OpenJ9? According to the AdoptOpenJDK website, OpenJ9 is designed for low memory usage and fast start-up time.
AdoptOpenJDK builds are not tested with the TCK due to a disagreement with Oracle. They do test with a suite of functional, integration, and performance tests. They also test popular framework libraries, languages, and applications.
Amazon is the new vendor on the block that’s offering builds of OpenJDK at aws.amazon.com/corretto. Amazon Corretto 8 (based on Java 8) is in preview; there is no Java 11 build available. Corretto is unique in that it has no-cost long-term support from Amazon. It’s builds have passed the TCK. Java 8 support is currently slated to run through June 2023.
Amazon also offers paid support for Corretto. All AWS instances that run Java use Corretto by default.
Azul builds and publishes Zulu at azul.com/downloads/zulu. It’s an OpenJDK build that’s passed the TCK and is fully compliant with the Java SE standard. Zulu Enterprise is Azul’s commercial offering with paid support. It provides long-term support for eight years after the version’s initial release.
Microsoft’s Azure platform uses Zulu for its Java support.
Oracle builds and publishes OpenJDK builds at jdk.java.net. Binaries are only published for the first six months after a major release. The branded, commercial version (that can’t be used in production without paying Oracle) is available at oracle.com/technetwork/java/javase/downloads.
jdk.java.net is where Oracle’s OpenJDK builds are published for download, openjdk.java.net is the OpenJDK project itself.
Red Hat distributes OpenJDK builds via Red Hat Enterprise Linux, a commercial product. It also has an IcedTea project that builds OpenJDK and adds some features. However, it doesn’t seem to be very active (there’s no Java 11 support) and you hardly hear about it anymore.
The JDK I use is largely determined by the tool I use to install Java. I used to download and install Java manually. When I did that, I used Oracle’s JDK. These days, I use SDKMAN!, a command line tool that installs and manages versions for me. SDKMAN determines the distributions I use today.
SDKMAN is all about convenience. The project aims to make it as easy as possible for you to install Java. If you run
sdk install java, it installs Azul Zulu 8. This is because java.net does not provide an OpenJDK distro for any version less than 9.0.
To see the versions available from SDKMAN, you can run
sdk list java:
================================================================================ Available Java Versions ================================================================================ 13.ea.02-open 1.0.0-rc-9-grl 12.ea.26-open 1.0.0-rc-8-grl + 11.ea.26-open 11.0.1-zulu * 11.0.1-open + 11.0.0-open 10.0.2-zulu 10.0.2-open 9.0.7-zulu 9.0.4-open 8.0.192-zulu 8.0.191-oracle > + 8.0.181-zulu 7.0.181-zulu 1.0.0-rc-10-grl
You can see from this list that I have Azul Zulu 8 as my current JDK, and I also have OpenJDK 11 (
11.0.1-open) installed. Who built the OpenJDK 11 version I’m using? I assume it’s the one from jdk.java.net, but I don’t really care. It works, and I love using it! However, I can only use Java 11 when working on Spring Boot 2.1 projects, so I don’t get to use it every day. I do a lot of maintenance on Spring Boot examples, and JHipster still uses Spring Boot 2.0. The good news is it’ll be upgrading to Spring Boot 2.1 very soon!
Long story short: Use whichever JDK SDKMAN gives you, and move on!
I figured it’d be fun to interview some of the Java experts here at Okta and get their thoughts on which JDK to use.
Brian Demers: I’ve been using Java since 1.3 the early '00s and remember the days when XML the solution to all problems. My career seems to have lead down the path of build tools and web security. This has also forced me to support using JVMs on a variety of systems. I’m also passionate about the OSS world and contributed projects like Sonatype’s Nexus, Apache Maven, and Apache Shiro.
Micah Silverman: I’ve been using Java since its initial release in 1995 (AWT anyone?). The first thing I ever wrote was an applet for the SyFy Channel (SciFi back then) that was an online Ouija board where the answers you got were from a dictionary of SF, horror and fantasy terms. I took a sharp turn from there into large banking and insurance companies, all of which became Java shops fast. I taught Enterprise Java at New York University as an adjunct professor and got to co-author a book on EJB 3.0.
Brian Demers: The community, It’s very easy to find existing quality projects from one of the bigger foundations like the Apache Software Foundation or Eclipse Foundation, as well as finding any number of instructional blog posts.
Micah Silverman: I love the way the language and community continue to adapt and evolve over the years. There seems to be an "Is Java dead?" post every year or two since its release. It’s remained a relevant and hugely adopted language (and put my daughter through college) because it hasn’t grown stale or fixed. There was a time when Java was first released for Linux that it only supported "green threads". These were virtualized threads and the performance was terrible. There were lots of "Java will die" articles during this period. But eventually, the builds supported native threads, the binaries became leaner and faster and now Java is on billions of devices around the world. Even with the bumpy road that it’s been with Sun and now Oracle’s stewardship, the open nature of the language and JVM specification has kept it growing.
Brian Demers: Currently Corretto:
$ java -version openjdk version "1.8.0_192" OpenJDK Runtime Environment (build 1.8.0_192-amazon-corretto-preview-b12) OpenJDK 64-Bit Server VM (build 25.192-b12, mixed mode)
Recently, I was running GraalVM more or less by accident, I installed it to play around with the "native-image" options, and a couple weeks later, realized it was still on my path. Creating a single binary from a Java project has me excited for the possibility of creating easy to install CLI tools.
I’ve been burned by OpenJDK in the past, so I was pretty hesitant to switch, but I haven’t run into any problems yet.
Micah Silverman: Currently Oracle (I use jenv to manage versions):
$ jenv versions system 1.8
I also have OpenJDK 11 installed.
Demers: This is tricky one, many of us are still going to be supporting a minimum version of Java 8 for a while. Generally, I’d say for development, use what you are using in production, but for things like library development, it’s definitely time to move to an OpenJDK distro. For production, I suggest starting with what is readily available on your platform (Amazon, Red Hat) and switch later to a different distro later if you need to.
Micah Silverman: For me today, it’s squarely Java 8 in development and production. That’s because the people I support are primarily using Java 8. That said, I set a goal for myself to update my relevant blog posts and examples as well as the production code I’ve written for my team to Java 11 this year. We’ll see how that goes. I was pissed that while the incorporation of Jigsaw with Java 9 and above is awesome, it essentially broke existing code immediately. I would’ve liked to have seen a "compatibility mode" or some such to ease the transition. But, the route of "pulling the band-aid" is not terrible either. I just haven’t gotten there yet.
I asked Les Hazlewood about OpenJDK versus Oracle. Here’s what he had to say:
"The only time the OpenJDK builds have been a big pain for me is that they were woefully behind the Oracle JDK’s implementation for TLS cipher suites and TLS version (1.1, 1.2) implementations. However, the open-source projects I work on have a pretty large exposure to diverse crypto algorithms and reverse-proxy types of workloads which leverage these things pretty deeply, so that very likely may not represent the types of issues others might encounter with standard web apps or microservices when trying OpenJDK. Especially if OpenJDK 11 and later are supposedly more aligned with the Oracle JDK releases.
That said, I am fairly nervous about the ability to receive timely bug fixes and point revision patches over OpenJDK’s lifetime. With the new Java versioning strategy, the only way to obtain those patches long term without paying would be to upgrade as soon as possible to the latest stable releases (11, then 12, then 13) as soon as they’re released. That can potentially significantly increase build/ci/test compatibility burden. However, given that these releases are time-based – and not as much feature-based – the amount of conflicts you might see from version upgrades after getting to the 11 baseline I would expect would be much, much fewer than what most people experienced going from version 7 to 8. So this could be attainable but definitely increases testing and rollout workload for software engineering and operations teams. Not fun but doable.
I also have had some exposure with the Azul guys in the past. It was a while ago, but I was quite impressed with their garbage collectors that came out long before JDK 8’s dynamic collector. I think Azul customers haven’t had to deal with PermGen Space Exceptions for almost a decade now, if not longer. Their engineering team at the time I engaged with them was extraordinarily smart, and assuming they’re still staffed with such folks, I personally would feel confident using their JDK implementations in production after suitable testing.
Given that people can’t use JDK 11 or later in production without paying, my particular take on a pragmatic approach for an engineering team would be:
There you have it. A plethora of opinions about which JDK you should use in development and production. In reality, you might not have an option of what distribution you use in production. If you’re using a cloud provider, they might dictate the distribution and version for you.
Java Fundamentals: Learn Java for absolute beginners
Learn Java Programming Using Practical Assignments. Start Building Back-end Web Applications Robust Test Automation Frameworks By End Of The Course. Learn More!
Fundamentos de Java: Aprende Java desde cero, sin misterios