Java is a massively overloaded word. For a start, it is the name of an Indonesian island as well as being a term for coffee. Then we have Java, the computing platform. Even then, the word has several meanings: are we talking about Java the programming language syntax, Java the virtual machine or Java the Development Kit (JDK)? There are many more ways we can use the term Java: card, embedded, Micro Edition and Enterprise Edition (at least now we have the disambiguation of this being Jakarta EE). I’m sure there are many more.
Where am I going with this? Well, as part of some work I was doing on a whitepaper for JDK migration I was compiling an exact list of differences between the Oracle JDK and Zulu JDK, which is a straight build of the source provided by the OpenJDK project. Since I’m also on the Expert Group for the Java SE specification, this got me thinking about how we define what is and isn’t part of Java (which then led me to think about what we actually mean by Java).
At about the same time as JDK 9 was released last year, Oracle made a number of announcements about how the JDK would be developed and delivered in the future. I’ve written about much of this before, but one part of this was the elimination of all functional differences between the Oracle JDK and one built from OpenJDK source. This work will be complete when JDK 11 is released later this year and involves both the addition of components to the OpenJDK project as well as removal of features from the Oracle JDK.
Much of this has been well publicised already. What were commercial features such as application class data sharing, Java Flight Recorder and Java Mission Control have all been contributed as open-source by Oracle to the OpenJDK project. Other features like JavaFX, the browser plugin and Java Web Start will all be dropped from the Oracle implementation of JDK 11.
The point that I’m trying to get to is how this actually gets defined. It’s useful to put this into a Venn diagram to understand things a little more clearly.
The smallest section is Java SE. This is the specification defined by the JSR through the JCP. If you want to create something that can be called Java, then this is the minimum set of requirements for what you need to provide. This includes the standard set of libraries (all the java and javax packages, plus some org.xml and org.w3c ones) as well as a JVM that can process the defined set of bytecodes. The JVM is defined in terms of functionality, like that it requires a garbage collector, but not how it should be implemented.
At the next level, we can learn what is OpenJDK. This is the reference implementation for the Java SE standard so naturally contains everything in that. It also includes things not defined by Java SE. Things like the JavaScript engine, Nashorn, are part of OpenJDK but not Java SE (the Java SE spec defines an interface to a scripting engine but not the implementation of any such engine).
Since OpenJDK is a superset of Java SE, the OpenJDK project came up with an alternative way to define new features of the OpenJDK. These are called JDK Enhancement Proposals (JEPs). Although not a formal standards process, this is an open process. Anyone who has committer status for OpenJDK is free to submit a JEP. Of course, since we’re dealing with the core Java platform, used by literally millions of developers, it is not a given that submitting an interesting idea as a JEP will get it accepted (far from it, in fact). To date, only one feature JEP that changes the API has been successfully submitted, accepted and released by someone outside Oracle. That was JEP 285, Spin-wait hints from us here at Azul. This is the addition of a single method to the Thread class that, in many implementations, will do nothing. The amount of effort and review that we needed to go through to get this into OpenJDK was substantial. Again, given the widespread use of Java, this is quite reassuring.
There are a few more non-Oracle JEPs that are for different ports of the JDK (JEP 175 and JEP 294 from SAP and JEP 237 from Red Hat) and one that will be included in JDK 11 (the Epsilon garbage collector, JEP 318, from Red Hat).
Interestingly, the term JEP has more recently become something of a misnomer. Two JEPS, 313 and 320, describe the removal of features. I guess you can enhance something by removing things, but this does seem a little counter-intuitive.
Finally, we have the Oracle JDK. Since this is Oracle’s binary distribution of the OpenJDK, they are free to add whatever features they like to add value. JavaFX is an excellent example of this. JavaFX has its own open source project (OpenJFX), which is separate from OpenJDK. JavaFX was never integrated into the Java SE standard (unlike AWT and Swing). Removal of features like this is entirely at Oracle’s discretion, but they have been reasonably good about publicising things like this through their various blog posts (more of this a little later).
Let’s return to what I said earlier about researching the differences between OpenJDK and the Oracle JDK. As part of this, I did a straight diff on the list of modules in JDK 10 and JDK 11. It turns out 31 modules have been removed and two have been added.
Firstly, there is the removal of the java.se.ee aggregator-module. This references six modules that are part of Java SE so have been removed from the Java SE 11 specification. The aggregator module and two related jdk specific modules are not part of the Java SE specification. JEP 320 describes the complete changes to the JDK.
- java.se.ee
- java.activation
- java.corba
- java.transaction
- java.xml.bind
- java.xml.ws.annotation
- java.xml.ws
- jdk.xml.bind (non-Java SE)
- jdk.xml.ws (non-Java SE)
The HTTP/2 incubator module (introduced in JDK 9) has been removed and replaced with one that is now part of the Java SE standard. This is described in JEP 110, JEP 321 and the Java SE 11 specification.
- jdk.incubator.httpclient replaced with java.net.http
The modules for JavaFX. As I mentioned, these modules are only included in the Oracle JDK, although JavaFX is part of the wider OpenJDK project. The news of their removal was announced here.
- javafx.base
- javafx.controls
- javafx.deploy
- javafx.fxml
- javafx.graphics
- javafx.media
- javafx.swing
- javafx.web
There are two JDK-specific modules for the related Java packager.
- jdk.packager
- jdk.packager.services
The browser plugin and Java Web Start modules. The removal of these features was publicised here. The modules here are mostly Oracle specific, but there is also the java.jnlp module.
This module had me quite confused. According to the JDK documentation, all Java SE modules have names that start with java, but it seems not all modules that start with java are in Java SE since java.jnlp is not part of the standard. It is, however, defined by the JCP as JSR 56. As such, according to JEP 200, which describes the Modular JDK, the module name starts with java. The reference implementation of JSR 56 was never released as open source, and so is only part of the Oracle JDK.
- java.jnlp
- jdk.javaws
- jdk.plugin
- jdk.plugin.server
- jdk.deploy
- jdk.deploy.controlpanel
Then there are the miscellaneous modules. There are two that are clearly Oracle specific because it’s included in the name. It seems that because these are desktop and net modules, they have been prefixed with oracle rather than jdk to prevent confusion.
- oracle.desktop (Oracle AWT utils)
- oracle.net (SDP and NIO Oracle additions)
Finally, we have three other Oracle-specific modules. In these cases, the removal of these features does not appear to have been announced anywhere other than the fact that the documentation for JDK 10 states that they are deprecated. I’m a bit surprised the removal of SNMP support was not announced somewhere (please correct me if I’m wrong, but a standard search did not reveal anything).
- jdk.management.resource (Resource management)
- jdk.management.cmm (Co-operative memory management)
- jdk.snmp (SNMP support)
At least from JDK 11, the Venn diagram shrinks to only two circles: OpenJDK and Java SE.
I plan to discuss the relationship between the JCP and OpenJDK and how Java features get added or removed in more detail in a later blog post.
NOTE: This post has been updated from its original form to correct some errata and add clarifications.
