Which Java SDK Should You Use?

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.

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:

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!

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:

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):

I also have OpenJDK 11 installed.

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: