The OpenJDK Mobile project is back!

JAXenter: You released the Gluon Client Plug-ins, which allow you to run Java applications on iOS devices. How is this technology possible?

Johan Vos: Apple does not allow apps that generate code while running on a device. Hence, the typical Java VM approach does not work, as this approach uses a compiler to compile bytecode and generate native code while running. However, by compiling the Java bytecode Ahead Of Time (before the app is submitted), the plugins move the compilation phase-out of the runtime, and towards the build time. This requires an AOT compiler (which we use the GraalVM compiler for) and static libraries for both Java and JavaFX, which we build from the OpenJDK and OpenJFX open source code repositories

JAXenter: The blog post for the announcement is called “Java on iOS, for real”. – And indeed, there have been repeated attempts to bring Java to iOS devices. What is the difference between your approach and earlier attempts? Why “for real”?

Johan Vos: Instead of creating something in parallel with the core Java and JavaFX development, we try to improve those crucial projects so that they work on mobile as well. That has a number of advantages: we leverage the great work done in those projects, we immediately benefit from bug fixes and new features in those projects, and developers really use the same Java on mobile as they are used to use on desktop and server.

It took some time before we had our approach working. GraalVM, OpenJDK and OpenJFX are complex projects, providing lots of functionality. But the integration work is done, and we can now benefit from changes in those 3 upstream projects. Hence, in our approach, it took a long time to get the basics running, but the basics are now stronger than ever before, and maintaining the project, including staying on par with new features in Java, will be much easier than with other approaches.

JAXenter: Java on iOS – why should you do that at all? From your point of view, what are the advantages of such an approach?

Johan Vos: Java is the leading language in many areas, and there is a large number of Java developers working with a large number of frameworks. A Java application written for Windows, works on Mac and Linux as well, without the Java developer having to learn something Mac or Linux specific. An advantage of Java on iOS that all Java developers can now use their existing skills to run applications on iOS devices.

Many companies already have an existing backend written in Java, with a web-based front-end. Those companies are increasingly getting requests to create a mobile front-end as well. Thanks to Java on mobile, the existing Java teams in those companies can control the development of mobile applications. There will still be the need for graphical designers and UX experts, but with the backend team and the mobile team sharing the same skills and languages, the integration between mobile apps and enterprise infrastructure becomes more smooth and secure. Security is one of the cornerstones of Java. With an increased interest in privacy and security, it makes sense to use the Java security on mobile, and for communicating between mobile and enterprise.

JAXenter: The Gluon client plug-ins are based on the GraalVM – a technology that is becoming more and more popular. What makes GraalVM currently one of the most exciting projects in the Java ecosystem?

Johan Vos: Looking at performance, the current generation of JIT compilers (e.g. hotspot) does an excellent job at runtime. The codebases are often hard to maintain though, and a compiler written in Java is easier to maintain for Java developers. Furthermore, Graal with its AOT compiler allows for very fast startup time. This is important in e.g. serverless functions, where the lifetime of the VM is typically shorter than the time needed for the JIT compiler to do its work; but also for consumer apps where a slow startup negatively impacts the user experience.

On top of that, the polyglot characteristics of Graal make it very easy for today’s polyglot development to combine e.g. Java and Python in the same environment and share data structures.
To be clear, Graal is not a replacement for OpenJDK. We also use the core API’s and their implementations, and the syntax of the language that are developed in OpenJDK. OpenJDK provides a top-quality platform, and the duo GraalVM and OpenJDK is the killer combination.

JAXenter: You have worked with the GraalVM team to go the last mile to support iOS devices. What was the collaboration like – what was the biggest challenge?

The GraalVM team was in the midst of finalizing the first release of the GraalVM Enterprise Edition while we were working on new functionality that was required to make it work with Java 11, JNI, LLVM, AArch64. However, the team has been extremely open, flexible and pragmatic. We tried to stay as close as possible to the master development branch of Graal, while still being able to use experimental new features. Pushing new features upstream requires passing a number of CI tests, and therefore the quality of the existing code can be guaranteed while still allowing new code.

JAXenter: Gluon relies heavily on JavaFX and is actively involved in the OpenJFX project. What has happened in the JavaFX development over the last few months?

Johan Vos: It took a while for the JavaFX ecosystem to get used to modules and to the faster release cycle. We are now in much more smooth water, and the JavaFX development is going very well, with a number of contributors working on specific features. One of the most important things that are currently under development in JavaFX, is the integration of third-party native rendering systems with the JavaFX native rendering. A number of developers are currently working on an API that allows doing this, and this will open the door for many projects that require very specific rendering to use JavaFX as well. In general, we try to lower the barriers for projects to use JavaFX.

With Gluon, we are of course working as well on making sure JavaFX works first class on mobile. With the JavaFX 8 family, the code difference between JavaFX for desktop and JavaFX for mobile was pretty large. For JavaFX 13, the difference is much, much smaller, and we hope to have 0 difference by JavaFX 14.

In general, the focus of OpenJFX is to provide a very solid, mature and flexible base for Java developers to create client applications with a focus on performance and user experience. Rather than providing an extensive set of UI elements, OpenJFX focusses on the foundations, making sure third-party libraries, frameworks, tools, and projects can focus on their specific functionality without worrying about the underlying components.

JAXenter: Back to the Gluon Client Plug-ins themselves – what is the current state of development?

Johan Vos: We have early-access for deployment to MacOS and iOS, with Linux coming very soon. We have samples for the basic HelloWorld and HelloFX, which contains a very basic JavaFX application. This allows developers to experiment with it, and to become used to the approach.

JAXenter: Finally, what are your plans for the future?

Johan Vos: As said, we only are at the start point now but we are confident we can move fast now. Obviously, we will support more targets (Windows and Android). Also, the developer experience is very important to us. We want to improve the tools, integrate with IDE’s, and make it easy, intuitive and familiar for Java developers to create mobile apps using their favorite tools. Specific for mobile, we’ll work on more integrations with mobile-specific functionality.

We are also continuing to improve our Gluon Mobile and Gluon CloudLink offerings, which allow creating real shiny mobile apps that integrate easily and in a secure way with cloud and backend infrastructure.

Thank you very much!