JavaFX 14: “There’s no need to use an older version of JavaFX when doing mobile development any more.”

JAXenter: JavaFX 14 / OpenJFX 14 is here, once again right before the Java 14 release. Will JavaFX 14 work with JDK 14 right away, or will people have to wait for a future release to enjoy the new functionalities of JDK 14?

Johan Vos: Developers can immediately use the JDK 14 features once JDK 14 is released. JavaFX 14 will work fine when using JDK 14. We didn’t raise the bar for the minimal required level for using JavaFX, which means that developers that are using Java 11 or above will be able to use JavaFX 14.

This is a consequence of an important set of design goals:

• We want developers to be able to use the latest new features in the JDK from day 1.
• We don’t want to force developers to upgrade to the latest versions of the JDK.

JAXenter: What features does OpenJFX 14 / JavaFX 14 have in store for its users? Any highlights?

Johan Vos: Our first priority is that the JavaFX API’s that are used in developer applications and libraries work first-class on evolving infrastructure. That means we need to provide support for new tools and libraries, and for changes in the underlying operating systems. In the Linux world, the transition from GTK2 to GTK3 deserves attention, and Apple created some interesting challenges with the Catalina release.

While we make sure that developers can use the latest operating systems and libraries, we also support older systems. This is a challenge in every release. We want to keep the OpenJFX code base clean for a very long time, so rather than quick patches for new or modified low-level functionality, we think very hard about the best approach that allows long-term maintenance.

The Webkit and related libraries got an upgrade, and some general code cleanup was performed. Based on input from (library) developers, a number of fixes and clarifications in the controls have been integrated.

We also made it possible to use the JavaFX platform in statically linked environments, using GraalVM.

• Added missing API to allow third-party controls to customize or extend TableView (see JDK-8207957)
• Add tabSize property to Text and TextFlow (see JDK-8130738)
• Support HTTP/2 in WebView (see JDK-8211308)

SEE ALSO: Introducing new JVM language Concurnas

JAXenter: The developers behind JavaFX 14 again focused on the usage of JavaFX on mobile (iOS/Android). What new changes/benefits does JFX 14 bring to the end users of the framework?

Johan Vos: Before JavaFX 11, the mobile JavaFX development was done in a separate repository, based on old snapshots. With JavaFX 11 on mobile, we started with a clean fork of OpenJFX, and added the mobile-specific parts in this fork. With every subsequent release, the difference between this fork and the main repository became smaller.

With JavaFX 14, we rewrote the integration with the Android native windowing system, and that code went straight to OpenJFX. This is ongoing work, and a number of mobile changes (e.g. webkit for iOS) is already pushed in OpenJFX and scheduled for JavaFX 15.

The important consequence for developers is that this approach allows them to stay on par between desktop and mobile editions of JavaFX: the same API’s on desktop work on mobile as well. There is no need anymore to use an older version of JavaFX when doing mobile development.

JAXenter: There were some problems regarding the usage of JavaFX in combination with GraalVM. What kind of issues were there and how did you guys solve them?

Johan Vos: First of all, GraalVM contains a number of components. The main component we are working with (and on) is the native-image tool, that precompiles Java code ahead of time, and that can make a statically linked image.

We had to do some tweaks to find the optimum balance between flexibility and performance.

This introduces a fundamental difference: in a typical scenario, a user somehow obtains a JavaFX application, and when running it, the required jar files and libraries are assumed to be present. This is no longer required when using an image created by native-image, as that already contains all libraries. This means though that we needed to create static libraries for the JavaFX components, instead of dynamic libraries.

Also, the GraalVM AOT compiler tries to do as much work as possible during build-time. Therefore, the build can take a long time, but application startup is much faster. Building is something that only the developer needs to do, while application startup is something that is done and noticed by the end-user. Hence, thanks to GraalVM, the end user will typically be more happy since his application starts up very fast.

There are some implications though, as not everything can or should be compiled or evaluated at build time. We had to do some tweaks to find the optimum balance between flexibility and performance.

Rather than modifying things in a rush to make everything working on GraalVM, we looked at a number of conceptual differences between linking with shared libraries versus linking with static libraries. We are working with the different involved development teams (OpenJDK, GraalVM and of course OpenJFX) to come up with the best approach. In the spirit of Java. quality and maintainability is extremely important. We want to ensure that the top-level API’s for JavaFX are behaving the same in different configurations. The mobile and embedded platforms are considered in this discussion as well.

Since GraalVM native-image requires some configuration (e.g. developers need to come up with a list of classes that should be considered for reflection or JNI access), we created Gluon Substrate, which does the major part of that configuration for the developer, and which adds specific support for JavaFX. We are gradually adding functionality, e.g. support for Media and WebView. Some of this support will be available in 14, while the remainder is scheduled for 15.

SEE ALSO: Solving JavaFX’s CSS problems with cljfx css

JAXenter: Are there any other major bugs that were addressed in this release?

Johan Vos: There are about 50 bugs fixed in JavaFX 14, and the list can be obtained here: https://github.com/openjdk/jfx/blob/jfx14/doc-files/release-notes-14.md

Some bugs have been in JavaFX for a very long time, and are now fixed because developers ran into them and provided patches. Other bugs are introduced because of changes in the lower-level operating systems. It is probably not surprising that in this release, we had to fix a number of bugs that were introduced by running JavaFX applications on the latest Apple operating systems, MacOS 15 (aka Catalina).

JAXenter: As always there are dependencies that needed updating; what do developers have to keep in mind when upgrading to JFX 14? Which dependencies were updated?

Johan Vos: We didn’t force new dependencies for this release. Some operating systems changed their dependencies though, and we tried to make sure developers don’t have to install additional packages.

JAXenter: Security is a big topic. Were there any changes related to making the usage of JavaFX more secure?

Johan Vos: As usual, the security patches in this release are mainly focused on web and media components. Those are the most vulnerable parts, as they involve external code that is not always as type-safe or secure. The OpenJFX developers carefully follow evolutions in these components, and security patches are applied whenever needed.

JAXenter: JavaFX is acting as pilot project for the migration from mercurial to GitHub. If everything goes to plan, the JDK might as well do it the same way as JFX. How are things going there?

The Skara team at Oracle is doing a great job in making it as smooth and powerful as possible to transition from the aged internal OpenJDK infrastructure towards the more modern GitHub.

Johan Vos: There is already a GitHub mirror for OpenJDK on GitHub, and the Skara tools are getting better every day. Those tools are needed in order to preserve the high quality and the required procedures for projects like OpenJFX and OpenJDK.

The Skara team at Oracle is doing a great job in making it as smooth and powerful as possible to transition from the aged internal OpenJDK infrastructure towards the more modern GitHub. More and more checks are now automated (e.g. if we indicate that a Pull Request requires 2 reviewers, that PR can not be merged unless 2 developers with reviewer status approved it), and the Skara team is very open and responsive.

As for the specific plans of the OpenJDK project, that is something that I can not comment on.

JAXenter: What is your personal highlight of this release and why?

Johan Vos: I am really happy that we could address the MacOS 15 issues so quickly. When Apple released this new version, there were a number of things that were broken. It’s not always trivial to get clear and open developer documentation in this area, but many people worked together and at this moment, I’m very happy that JavaFX 14 runs very well on Catalina.

Also, I’m very excited to see the difference between the mobile/embedded code and the mainstream code being so small.

JAXenter: Any plans for JFX 15 yet?

Johan Vos: Yes. Actually, JavaFX 15 development is already very active. We tend to do big things in the early phases of a new cycle, so that they can be tested very well. We are adding more support for mobile: the webview code for iOS got a major overhaul, and the code for using software keyboards on mobile is being refactored as well.

We are also working to make the JavaFX code up-to-date with the latest evolutions in the JDK, and one of the things that is ongoing is to remove the deprecated finalize methods in the code base.

Thanks very much for talking to us!

The post JavaFX 14: “There’s no need to use an older version of JavaFX when doing mobile development any more.” appeared first on JAXenter.