The recent ‘news’ about Android moving from Harmony to OpenJDK caused some confusion and lots of speculation in the developer world. In this post, we try to clarify the facts without going into any speculation.
1. Terminology
First of all, some terminology needs to be clear. There are a number of components involved which can be divided into a number of layers.
1.1. JVM
The Java Virtual Machine is responsible for executing Java bytecode. There are a number of options for doing this. Bytecode can be interpreted, compiled to platform-specific native code at runtime (JIT a.k.a ‘Just In Time’) or compiled to platform-specific native code before runtime (AOT a.k.a ‘Ahead Of Time’).
Currently, Android uses its own ART runtime. Developers targeting Android devices (e.g. native Android developers or a JavaFX developer) write Java code, which is compiled into Java bytecode by a Java compiler. The Android SDK (which is also used by the jfxmobile plugin that allows to run JavaFX applications on Android devices) translates the Java bytecode into dex bytecode which is packaged into an Android Package. Recent versions of the Android Platform contain the ART runtime, which provides an AOT that translates dex bytecode into native code.
OpenJDK contains the HotSpot VM, which provides a JIT for Java bytecode, and a Zero Interpreter VM. The recently announced Mobile subproject of the OpenJDK makes this VM available on Android systems (using HotSpot for x86 CPU’s and Zero for arm CPU’s).
In summary, there are a number of virtual machines that can be used when running applications on Android devices. Each have their pro’s and con’s but all of them should be capable of executing the Java bytecode generated by the Java compiler from your Java source code.
1.2. The Java Class Libraries
The Java Platform, Standard Edition 8, defines a number of Java Classes (e.g. java.lang.String). Developers use these standard classes to write their code. Libraries and UI frameworks build on top of these classes.
Currently, Android uses Harmony, an open source Java implementation by the Apache Software Foundation. Harmony was officially retired in 2011.
The OpenJDK project provides an implementation for the Java class libraries. This implementation is also the Reference Implementation for Java SE, and is thus by definition always up-to-date with the specification.
2. The changes
2.1 The ‘move’ from Harmony to OpenJDK
From the commit message in the Android repository, it seems Android will at least use the Java Class libraries from the OpenJDK project. It is not clear whether Android will continue with its ART runtime, or if it will switch to an OpenJDK engine (e.g. HotSpot).
2.2 What does this mean for OpenJDK?
The key message is that this makes OpenJDK even stronger and more important. Most of the big players in the Java world are part of the OpenJDK project, and contribute code into it. The list includes Oracle, IBM, Red Hat, Apple, SAP and Twitter. The companies participating in OpenJDK agree on a standard and compete on products and services leveraging the standard.
2.3 What does this mean for JavaFX?
This is excellent news for JavaFX. The OpenJFX project, the source for JavaFX development, is a sub-project of OpenJDK. It is very well aligned with OpenJDK and it provides the de-facto UI framework standard for Java.
In the JavaFXPorts project, Gluon provides a minimally modified version of OpenJFX that allows it to run on Harmony and to integrate with the Android Activity system. If Android moves from Harmony to OpenJDK, the required modifications for running JavaFX on Android will be even smaller and JavaFXPorts will be easier to maintain.
Of course, it will still be possible to create Android applications using the Android UI widgets. But with OpenJFX and OpenJDK being so well aligned, developers have yet another reason to consider JavaFX as their UI framework. The other reasons stay relevant as well, of course. Using JavaFX, you have a single codebase shared by all your deployments (desktop/Android/iOS) rather than having to maintain different repositories.
2.4 What does this mean for Gluon?
Gluon provides products and services for client Java development, on top of the JavaFX Platform. The underlying implementation details are hidden by the JavaFX API’s. As we wrote before we support a number of JVM’s and a number of configurations. Having said that, We have always been big supporters of OpenJDK and OpenJFX and we are thrilled to see the increasing popularity of OpenJDK.
3. Conclusion
Standardization matters. At Gluon, we are happy to see the OpenJDK project being successful. We are convinced the OpenJFX project provides similar benefits.