Interview series — Part 1

Now that JavaFX 11 is here and a new era has begun, it’s time to take a look back and a leap forward. We invited Johan Vos, Jonathan Giles, Dirk Lemmermann and Donald Smith to weigh in on the latest release, how the community should adjust to the latest developments and more.

JavaFX 11 is here

It’s time to meet the standalone JavaFX 11 release. You can download it by going to the openjfx.io site or by accessing javafx modules from maven central at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base, graphics, controls, and so forth), according to the message announcing the release.

Note: JavaFX 11 requires either JDK 10 (which must be an OpenJDK build) or JDK 11. JDK 11 is recommended. You can find the release notes for JavaFX 11 here.

You can develop JavaFX applications in two ways:

Download and install the JavaFX SDK

Use a build system (e.g. maven/gradle) to download the required modules from Maven Central.

A recent early access version of the Java 11 SDK is required for both options.

Now that JavaFX 11 is here and a new era has begun, it’s time to take a look back and a leap forward. We invited Johan Vos, Jonathan Giles, Dirk Lemmermann and Donald Smith to weigh in on the latest release, the difference between a JavaFX that’s been decoupled from the JDK and the old one under Oracle’s stewardship, how the process has changed and how the community should adjust to the latest developments.

4 answers: How is JavaFX different now than when it was under Oracle’s stewardship?

Meet the interviewees

Johan Vos: Oracle still provides the co-lead for OpenJFX, and still provides lots of engineering resources. The direction and goal of the project, therefore, didn’t change. The goal is still to deliver and maintain a high-quality framework that can be used by Java developers to create compelling client applications.

By creating a GitHub mirror though, we managed to get more interest from the community, and a number of developers provided their first commit ever to an OpenJDK project. Those developers also found the way to the core project infrastructure, and we see a large increase in traffic on the OpenJFX developer mailing list.

JavaFX is still under Oracle’s stewardship – it’s just that the community is more deeply involved than ever before.

Jonathan Giles: I would argue that JavaFX is still under Oracle’s stewardship – it’s just that the community is more deeply involved than ever before. Companies such as Gluon are now actively involved in maintaining aspects of OpenJFX (with Johan Vos an external, non-Oracle co-lead of OpenJFX, along with Kevin Rushforth from Oracle). Gluon is building releases, driving community projects like the JavaFX 11 project page, offering long-term support options, and much more, and the community are writing third-party libraries, offering custom consulting, and much more. Because it is more open to the community, and there is the GitHub mirror, OpenJFX is seeing far more community-contributed additions as well, which is super exciting.

Donald Smith: Oracle made tremendous progress since announcements early this year about making it easier for the Java community to work on OpenJFX. We’ve worked hard to help ensure that JavaFX can be built independently of a JDK which we felt was a critical step in ensuring the community could take on leadership. Johan Vos of Gluon has stepped up and co-leads the OpenJFX project in OpenJDK, which has delivered great results such as the availability of OpenJFX 11. We still see our role and contributions as critical to OpenJFX and have no plans to step aside anytime soon.

What needs to change about JavaFX now that it’s under the community’s stewardship?

Johan Vos: In that past, companies and individuals were mainly looking at Oracle for both defining and implementing the roadmap. By opening the project, it is becoming clear that OpenJFX is much bigger than what a single company can do.

We increasingly see other companies and individuals coming up with ideas, discussing them on the mailing list, and coming up with implementations. This process needs to continue. We need more companies to give input and to step up and do implementation work as well.

Oracle is still a great citizen in the JavaFX world, but there is a huge opportunity for other companies to co-shape the Java Client landscape.

Oracle is still a great citizen in the JavaFX world, but there is a huge opportunity for other companies to co-shape the Java Client landscape.

Jonathan Giles: I don’t think anything needs to drastically change. I think there needs to be work now to identify gaps that the community is able to fill (in terms of bug hunts, developing new features in a collaborative fashion, writing documentation, etc).

Dirk Lemmermann: I think it has to become a real open source project where contributions by the community are truly appreciated. It also needs to pick up the pace so that bug fixes and new features have a chance to make it into the next release.

Donald Smith: JavaFX continues to be developed via the OpenJFX project on OpenJDK. It has long been an open-source project, just like the JDK. The main changes have been around making it easier for developers to contribute fixes and improvements, and decoupling it from the JDK itself. Other changes will continue to be handled through the normal OpenJDK processes – like they were before – but driven by the community instead of just Oracle.

What has happened since it was announced that JavaFX would be decoupled from the JDK? Is the process more simple now?

Johan Vos: We still mainly follow the same procedures as the ones in OpenJDK, which guarantee quality, stability, maturity. On top of that, since we created a GitHub mirror, the community added automatic testing using Appveyor and Travis. This made it much easier for developers to work on pull requests and testing their code before asking for reviews.

Jonathan Giles: The process has changed, but I think it has changed in a good way. I think initially there will be some speed bumps as developers move over to the new approach (where the JavaFX libraries are shipped via Maven), but in the long run, I think the change in the process enables a more rapid development cycle and removes a dependency on the user having a particular Java version installed on their machine.

In the long run, I think the change in the process enables a more rapid development cycle.

Dirk Lemmermann: Definitely! There is now a single place where you can work on JavaFX and it is the OpenJFX repository on GitHub. Anyone can clone and fork the repository and build JavaFX on their own machine. Fixing a bug and providing a pull request is now as simple as for any open source project.

Donald Smith: The process for contributing fixes has been streamlined to make it easy for developers to test fixes and enhancements and then propose those changes for review to be included in JavaFX. We continue to look for ways to simplify this, while maintaining the high quality that JavaFX users have come to expect.

For example, before the recent changes, JavaFX was tightly integrated with the JDK. Although this might sound like a good thing, the result was that you couldn’t build a standalone version of JavaFX that could be used by different Java SE implementations, like OpenJDK and Oracle JDK. If you wanted JavaFX, you had to build the complete JDK with it. Now, after the de-coupling, it is possible to work on JavaFX independently of the “rest” of the JDK.

What’s your first impression of JavaFX 11?

Johan Vos: For JavaFX 11, the big thing for me is the fact that developers can now use JavaFX artifacts in the same way as they use other software libraries since the artifacts are now deployed on maven central. For developers who prefer an SDK, that is of course still an option.

Apart from that, JavaFX 11 has 9 enhancements and 90 bugfixes, compared to JavaFX 10.

The JavaFX 11 release is all about the decoupling from the JDK.

Dirk Lemmermann: The JavaFX 11 release is all about the decoupling from the JDK. It is not about new features. The release notes contain a nice list of bug fixes, a short list of enhancements, and only a single real new feature which is the “Robot API”.

Donald Smith: We hope that JavaFX continues to evolve to fit the ever-evolving needs of its users. One of the features we would hope to see going forward is to see it easier to integrate third-party UI controls into JavaFX.

In the next part of the interview series, we will focus on the evolution of JavaFX, the next release, the release cadence and more. Stay tuned!

By the way, if you’d like to learn more about JavaFX, including how to program JavaFX applications and how to bring your Java apps to mobile platforms such as iOS or Android with Gluon, don’t miss JavaFX Days Zurich in the first week of December.