Not surprising at all that the OpenJFX modules will be decoupled from the core

JavaFX as a separate module: A look back and a leap forward


© Shutterstock / Africa Studio

How has JavaFX evolved since it was announced at JavaOne in 2007? Was decoupling JavaFX from the JDK an inspired idea? In this article, Johan Vos weighs in on the news and explains why it makes perfect sense to move the development of JavaFX to an open system.

When JavaFX was announced in 2007, it was Sun’s first serious attempt to replace the aging AWT/Swing technologies with a more modern client platform capable of rendering user interfaces (UI).

One of the key features of JavaFX is a separation between the APIs that developers use to create user interfaces and the rendering engines that make sure the interface is rendered on devices. For Windows platforms, the JavaFX rendering pipeline uses Direct3D, while for the other platforms the rendering pipelines are based on OpenGL. Thanks to this separation, the JavaFX APIs don’t have to be changed when new hardware rendering techniques become available. JavaFX allows, in the spirit of Java, to create cross-platform applications that keep working when the underlying implementations are changed.

Initially, JavaFX was considered interesting to games etc. While that is still very well possible, a large number of the JavaFX developers is active in industries that require high-performance graphical operations on sensitive data. The combination of the JavaFX rendering APIs with the security functionality provided by the core JDK and third-party libraries allows for the creation of desktop, mobile and embedded apps that are mature, future-proof and visually attractive. Since many of these applications are developed and used behind closed company walls, it is often hard to estimate the popularity of JavaFX.

There is an increasing adoption of JavaFX in the scientific community — e.g. the Deep Space Trajectory Explorer.

With the growing popularity of AI and deep learning, JavaFX and Client Java, in general, are increasingly interesting to developers who want to leverage the Java platform and the JavaFX UI APIs while providing functionality that includes deep learning algorithms.

Compared to Swing/AWT, the JavaFX APIs are more aligned with today’s concepts of UI development, and the underlying rendering engines are leveraging hardware acceleration. Combined, this makes JavaFX a real modern UI platform that is still leveraging the benefits of almost 25 years of Java experience.

JavaFX is more than simply rendering user interfaces, and the platform contains a solid base for client development in general (taking into account threading, concurrency, observability etc.). As a consequence, there are many things developers can or should learn. There is a wide range of resources available, ranging from books over courses and tutorials.  It is remarkable that tutorials on Scene Builder, for example — the UI tool that allows creating a JavaFX user interface by dragging and configuring components rather than to program them ‚ are very popular on YouTube.

Starting with JDK 11, JavaFX will be available as a separate module, decoupled from the JDK

Recently, Oracle announced that the JavaFX modules will be decoupled from the core JDK distribution. Looking at the goals of modularity, this makes lots of sense. One of the core reasons why the Java platform needed a modular system is because the platform has been inflating a lot since its first release. Lots of functionality has been added to the core Java distributions (e.g. the Oracle JDK).  Almost all Java projects in production, however, also leverage third-party libraries. Developers rely on tools like Ant, Maven or Gradle to download dependent libraries from e.g. maven central or jcenter and to manage those dependencies. The advantage of this distribution mechanism is that a fine-grained control is possible, and you don’t have to tell your users to download the exact versions of the exact components you rely on.

Different components evolve at different speeds. While backward compatibility is one of the key features of Java, in many cases developers rely on a specific version of a library to be used in their application. If that library was hard-baked into the core JDK, that would have serious consequences, as the JDK is still a monolithic piece of software that you download and install manually on your system.

The core of the JDK is a wonderful piece of art that is maintained by very talented engineers. In order to guarantee the quality of this core, especially with fast release cycles, whatever components that can be maintained outside of the core should be maintained and released separately.

Therefore, it is not surprising at all that the OpenJFX modules will be decoupled from the core — it is rather surprising that there are still that many other modules in the core.

Traditionally, JavaFX has a very strong, wide, and vocal ecosystem. There are many libraries based on JavaFX created by third parties, and JavaFX has been ported to different platforms, including embedded and mobile  (Android/iOS) outside of Oracle.

Hence, it makes perfect sense to move the development of JavaFX to an open system. The GitHub repository is a reflection of this idea. Today’s development increasingly happens on GitHub, and by inviting third-party developers to contribute to the JavaFX platform via GitHub, JavaFX moves more towards an open, developer-friendly platform.

The increasing involvement of the Java development community in core Java development is not a new thing. The AdoptOpenJDK project is a community-organized initiative that has been working for a couple of years now to create distributions based on the OpenJDK source.

In the future, the JavaFX modules can be built leveraging the AdoptOpenJDK infrastructure, and the resulting artifacts can be uploaded to platforms like Maven central and jcenter. Discussions about this topic between Oracle and the wider JavaFX community are ongoing.

Johan Vos started working with Java in 1995, as part of his PhD research. He joined the Blackdown team and ported Java 1.2 to Linux/SPARC. Johan has been a Java consultant ever since, and worked for a number of companies (e.g. The Reference, Acunia). He co-founded LodgON, where the main focus is on social networking software and recently became a Java Champion. He was part of the Core Platform Expert Group of OSGi that created the OSGi platform specifications. His main technology interests are currently GlassFish and JavaFX. He holds an Msc in civil engineering (mining) and a PhD in Applied Physics.

Leave a Reply

1 Comment on "JavaFX as a separate module: A look back and a leap forward"

Notify of

There was never really an official “announcement” by Oracle that they intended to do this, rather a standard white paper outlining their intentions. The first 72 hours after was a lot of nervous Internet “chatter”. This article is good because it very simply outlines the motivations and benefits for decoupling JavaFX as a separate module from the rest of the JDK for Java 11.
Thank you Johan!