Johan Vos (Gluon) is a longtime Java porter (including all the way back to the Blackdown days) who has been spearheading this work as the project lead of the OpenJDK Mobile project.
He told InfoQ that the concept of “One Java, that runs on any platform” remains key and that while Java remains a great option for performant, scalable and maintainable applications for backend and cloud systems, there is no reason why Java developers should not be able to use the language and ecosystem they love and are skilled at to create mobile applications.
The project is baselining on the Zero interpreter (so called because it is written in pure C++ and contains zero platform-specific assembly code). This is one of two different interpreters that Hotspot can be configured with at build time. Most Java builds use the “template interpreter”, which is based on dynamically building a dispatch table for bytecode when the JVM starts up.
“If developers write Java code, they expect that that code should run on any device that supports the same Java version. The major reason we focused on Zero in the past few months is that it allows us to stay aligned with the latest upstream OpenJDK code. Using Zero allows us to test all the JDK classes and features, and it allows to make a clear distinction between work on functionality and work on performance.” Vos explained.
Performance of Java applications on iOS is expected to have some challenges, because Apple does not allow apps to use runtime-generated assembly code, which not only excludes the template interpreter but also rules out a JIT compiler.
Despite this, Vos has been impressed by the performance of Zero, which he says “does an excellent job for being an interpreter. However, Zero alone is not enough to create highly performant iOS applications.” He also alluded to a previous approach, which used AOT compilers from RoboVM and GraalVM, to compile the required Java methods ahead of time, and then a modified VM to execute those methods. This technique allowed impressive performance (comparable with performance achieved when using Objective-C or Swift) but with the issue that this approach came with a VM that was not 100% aligned with OpenJDK.
Vos draws a comparison between Leyden and the partial-AOT approach used previously to run Java applications on iOS – where “some” of the Java methods are already compiled before an application starts running. He believes that a combination of Leyden (for creating native code ahead of time) and Zero (for running dynamic code that is not compiled ahead of time) can be a winning combination for Java on iOS, as it allows full execution without sacrificing the (often-underappreciated) dynamic character of Java.
A separate strand of work deals with compiling OpenJDK binaries for Android to execute unmodified Java applications – as opposed to compiling for the DEX bytecode format to be executed by the Android Runtime (ART). This is anticipated to be less technically complex than the iOS work, as the dynamic code restrictions are not present in the Android environment.
The current state of the mobile OpenJDK project can compile a VM and class libraries for both iOS and Android, and that can be deployed and run on real devices. Java library authors should be able to deploy their library with the current state, but the next step is to enable the conversion into a native library for iOS and Android.
However, many Java developers will want to create not just a library, but a whole application for mobile devices. This requires a GUI toolkit, and the approach Mobile OpenJDK is taking is to use OpenJFX for this capability. The base JavaFX libraries already compile on both iOS and Android, but more work is needed to integrate with the low-level platform-native graphical APIs to achieve hardware accelerated rendering.
The approach being taken by OpenJDK Mobile focuses on maintainability, and 100% alignment with OpenJDK. As a consequence, the complete set of developer-friendly tools yet that many programmers are familiar with is still being developed. However, Vos is confident that now the foundations are more stable, developers in different areas (compilers, tools, UI, libraries) will join the effort. The intention is to enable teams to create or integrate the current work into their projects and produce cross-platform tools and applications without having to worry about breaking changes coming from the lower levels.
