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:
Java started releasing new major versions every six months
Oracle changed their support model for Java
Here’s a quick summary of Oracle’s changes:
Oracle now distributes two JDK builds: Oracle JDK and Oracle OpenJDK
Oracle JDK is free for development and testing, but you have to pay for it if you use it in production
Oracle’s OpenJDK is free for any environment
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.
Java SDK Options
Currently, the only source code for the JDK is in the OpenJDK 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 a JVM that is designed for low memory usage and fast start-up time. A JVM runs compiled Java bytecode, while the Java language provides a syntax for how to produce that bytecode.
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 11 is scheduled to be released in Q2 2019. GA for Corretto 8 is Q1. Corretto is unique in that it has no-cost long-term support from Amazon. Its builds have passed the TCK. Java 8 support is currently slated to run through June 2023.
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.
Which JDK Should You Use?
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 ================================================================================ + - local version * - installed > - currently in use ================================================================================
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!
What do other Java Experts Think?
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.
Les Hazlewood is a senior architect at Okta. Before Okta, he was Stormpath’s co-founder and CTO. He’s also the founder and lead developer of the Apache Shiro and JJWT projects.
Brian Demers is the lead Java SDK developer at Okta and a major contributor to Apache Shiro, among other open source projects. By "lead Java SDK developer", I mean that he develops and maintains the Okta Java Management SDK and the Okta Spring Boot starter.
Micah Silverman is a technical instructor at Okta. Before Okta, he was one of Stormpath’s lead Java SDK developers.
First, can you provide everyone with some background on your experience with Java?
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.
What is your favorite thing about Java?
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.
What Java SDK are you using right now?
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 * 22.214.171.124 (set by /Users/micahsilverman/.jenv/version) 11.0 11.0.1 openjdk64-11.0.1 oracle64-126.96.36.199
I also have OpenJDK 11 installed.
What Java SDK do you recommend for development? For production?
Brian 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:
Upgrade to OpenJDK 11 as soon as possible. Oracle JDK 9 and 10 are not Long Term Support candidates and 11 is. Regardless of which JVM distribution you use, this will give you the most options with respect to time: if you decide to stick with Oracle, that will give you the longest/safest platform to build and deploy against due to 11’s Long Term support, albeit at a monetary cost.
Enable Zulu (Azul’s OpenJDK distribution name) JDKs (JDK 11 APIs) in your CI environment as soon as possible. These JDKs are free to use in dev and production without paying a license fee. You can decide to pay for 8x5 or 24x7 support if/when it becomes important enough for you to do so. At least testing this distribution this would give you an idea of what you’re up against, and it might just go more smoothly than expected. Assuming smooth testing, I’d be completely comfortable using Zulu in production."
Java Is Still Free
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".
Install Java Today!
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.
I found these blog posts helpful when writing this post:
If you liked this article, you might enjoy some other ones on this blog: