What is OpenJDK?

I talk to many people about how they use Java, and I find there is a high level of misunderstanding about what OpenJDK is.  The idea of this post is to provide a clear description of what OpenJDK is and isn’t.

Let’s start with some history.  Back in 2006, the management of Sun Microsystems (the original developer of Java) decided to make the source code of the Sun implementation of the Java platform available under an open-source license.  This decision had been influenced by several factors, not least of which many Java users had been asking for it.  The Apache Harmony project had started a year or so earlier with the express goal of providing an open-source implementation of Java.  Sun management felt that it would be better for their implementation to be the canonical source.

The initial announcement was made at the JavaOne conference in 2006. Later that year, most of the HotSpot virtual machine and compiler code was released under the GNU Public License (GPL) with classpath exception. 

As a side note, it’s also worth mentioning that the JVM included in all OpenJDK Java versions is HotSpot.  People occasionally think that HotSpot is synonymous with the Oracle JDK. Whilst the Oracle JDK does indeed include the HotSpot VM; this is only because it is part of OpenJDK.  All unmodified builds of OpenJDK, therefore, use the HotSpot VM. 

On May 8^th, 2007, the bulk of the code for the JDK class libraries was released (under the same license), and the OpenJDK project came into existence.  There remained several closed-source pieces that Sun did not have the rights to, but these were gradually replaced.   With the release of build 53 of OpenJDK 7, it was finally possible to build the entire JDK from open-source code. 

Understanding OpenJDK

If you look at the web page, the description is pretty unambiguous:

“The place to collaborate on an open-source implementation of the Java Platform, Standard Edition, and related projects.“

Donald Smith (Senior Director of Java Product Management at Oracle) is very clear about this, “OpenJDK is a place, not a thing“.  This is quite true; however, we can also think of OpenJDK in terms of the OpenJDK projects (which are things).  As you would expect from the definition, OpenJDK is organised into a set of distinct projects.  At the time of writing, there were 73 projects.  These encompass a wide variety of activities related to Java SE:

• From JDK 6 to JDK 9, each version of Java is a separate project.  Updates to JDK 7 and 8 also have projects independent from the initial implementation. However, with the switch to the six-month release cadence, all versions from JDK 10 onwards are covered by a single umbrella project.  Updates, likewise, are now covered by a single project.
• OpenJFX is the project for the open-source development of JavaFX.  Originally part of the Oracle JDK, this was removed as of JDK 11.
• There are several projects for more significant developments for the Java platform, such as:
  • Amber (small Java language features)
  • Loom (lightweight user-mode threads)
  • Panama (a replacement for JNI to interconnect the JVM with native code)
  • Valhalla (value types and generic specialisations)
• A wide variety of ports of the JDK to platforms such as BSD and AArch64.
• Several are what could be described as meta-projects in the sense that they provide things that projects need.  Examples are Code Tools, Developer’s Guide and Skara (the migration of the SCM from Mercurial to GitHub).
• Even Duke has his own project that provides free graphics of the great character.

The most critical aspect of OpenJDK when dealing with the JDK is that it only represents source code (in the form of repositories).  When I ask people which Java they are using, I will often get the response, “We use OpenJDK”. That’s fine, but it’s like answering “Linux” to the question of which operating system you use.  OpenJDK provides all the source code for the Java Development Kit but, to run an application compiled into bytecodes, you need a binary distribution of the JDK.  OpenJDK does not provide any pre-built binary distributions.  Even though the OpenJDK project is hosted on the java.net domain, the Oracle OpenJDK JDK binaries you can download from jdk.java.net are not part of OpenJDK.

OpenJDK is more than this, though.

The Java platform is defined by a standard created under the Java Community Process (JCP).  Each version of Java Standard Edition (SE) has a different Java Specification Request (JSR).  An expert group is formed for each JSR and produces three distinct deliverables:

1. A specification in the form of the Java Language Specification, the Java Virtual Machine Specification and javadocs for the required class libraries.
2. A Technology Compatibility Kit (TCK) can verify that implementations of the standard conform to the specification.  For Java SE, this is the Java Compatibility Kit (JCK), but almost everyone refers to it as the TCK.
3. A Reference Implementation, which demonstrates that it is possible to implement the specification.  For all releases since Java SE 7, this has been the corresponding OpenJDK project.

Whilst the reference implementation of each Java version is part of OpenJDK; it is still essential that any distribution built from OpenJDK code is verified with and passes all the tests of the TCK.  Even apparently minor things, like the version of a compiler being used or the command-line flags to that compiler, could, potentially, cause the resulting binaries to fail one or more tests. On the other hand, a TCK tested OpenJDK binary provides you with a high level of confidence (since no test suite can be completely exhaustive) of compatibility with another TCK-tested distribution.

What is not part of OpenJDK?

If you look at the Oracle JDK prior to Java 11, you will find some components that are missing from OpenJDK.  The most obvious of these are the Applet Browser Plugin, Java Web Start and JavaFX.  In the case of JavaFX, as already mentioned, this is a separate OpenJDK project, OpenJFX.  The other parts remain closed-source.

In the same way that you can choose different Linux distributions (Ubuntu, Debian, Red Hat, etc.), there are plenty of choices of OpenJDK binary distribution.  We here at Azul provide our Zulu builds of OpenJDK, both for free and commercially supported in the form of Azul Platform Core.  Almost all builds are TCK tested; the exception is OpenJDK 6 (since the TCK is no longer available).

Decisions about how the Java platform evolves has changed over the lifetime of the OpenJDK.

Although the specification of what is in each release of Java SE is still published through a JSR, the Java SE Expert Group no longer decides what to add or remove. Instead, this is now handled through OpenJDK using JDK Enhancement Proposals (JEPs).  JEPS collect, review, sort, and evaluate proposals for enhancements to the JDK.  The formal description of the JEP mechanics is described in JEP 1.  The goal of JEPs is to provide a roadmap of potential new JDK features that lasts for at least three years.  However, there is no intention that all JEPs submitted will end up in the JDK at some point.

In summary, then, OpenJDK is many things.  At its core, it delivers the source code used to provide users with a wide choice of distributions on which to run their applications.  It also provides an open and inclusive way to define the future of the Java platform.

Read the best practices for moving to OpenJDK.

Do you want to use OpenJDK to run your Java workload?  Then why not try Zulu? It’s free.