JavaFX 11: What’s changed, and what’s stayed the same
Now that JavaFX 11 is here and a new era has begun, it’s time to take a look back and a leap forward. If you’re wondering if the “new” JavaFX is worlds away from the “old” one, keep reading because our interviewees will answer this question and more.
“Developers who previously used JavaFX should feel that not much has changed”
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 have a look at what’s changed and what’s stayed the same. In the first part of this interview series, 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.
But if you’re wondering if the “new” JavaFX is worlds away from the “old” one, keep reading because our interviewees will answer this question and more. Just to give you an idea of what’s included in the second part, here is what Donald Smith told us:
The difference should be that now you simply treat JavaFX as you would any library that doesn’t ship with the JDK.
Don’t miss the first part of the JavaFX 11 interview series:
4 answers: How can people develop JavaFX applications, now that JavaFX has been decoupled from the JDK? What are the steps?
Meet the interviewees
Johan Vos: People can either download the SDK, and add the JavaFX modules to the module-path, or they can use maven or gradle and have those tools download the JavaFX modules from maven central. There is a getting started guide here.
I have already upgraded several of my commercial and open source projects and it has been a piece of cake.
Dirk Lemmermann: Normally we all use a build tool for our applications, either Maven or Gradle, right? So now it is simply a matter of adding the required dependencies to your build files. There is no difference between adding JavaFX or adding JUnit to your project. JavaFX does not require any special treatment at all.
I have already upgraded several of my commercial and open source projects and it has been a piece of cake. Nobody needs to be worried! If you do not use a build tool then there is the JavaFX SDK that you can download. The OpenJFX guys have published a tutorial on how to use it.
Donald Smith: Most of the work on decoupling JavaFX from the JDK was done so that the answer to this question remains “mostly the same as before”. The difference should be that now you simply treat JavaFX as you would any library that doesn’t ship with the JDK.
This has been a normal step for developing Java Applications for a long time given the large number of common frameworks and libraries offered by the Java community. Once JavaFX is downloaded and included in your applications, developers who previously used JavaFX should feel that, with this first release of JavaFX as a stand-alone library, not much has changed.
Development on JavaFX 12 has already started. Why does JavaFX follow the same cadence as Java SE and what are the benefits?
Johan Vos: The rationale behind the Java release cadence makes lots of sense, so we think it’s best to use that too. This allows developers to work on features that may take a long or unpredictable time, without holding up releases. At the same time, it gives users a very predictable path.
Apart from that, we try to align as much as possible with OpenJDK, especially when there are clear benefits.
There are obvious benefits in aligning OpenJDK projects with the JDK release timelines but there is no rule that this be so.
Jonathan Giles: There is no reason why JavaFX needs to follow the same release cadence as Java – there is no direct need for this anymore.
Dirk Lemmermann: I think the new release scheme for Java SE makes a lot of sense and I do not see why it shouldn’t do so for JavaFX as well. A different cadence would only cause confusion in the developer community.
Donald Smith: The JDK community has found real value in the faster six-month release cadence. By keeping to the same timing and release numbering, the JavaFX application developers will also benefit from that same rapid development.
One thing to note is that since JavaFX is now unbundled, we could decide to change the cadence at some point in the future if there was a good reason to change. So far no one has suggested adopting a different release cycle. Every library now has the chance to evolve and take advantage of new features in the JDK every six months. Some will do so, specially the ones that are trying to get new features and improvements delivered faster. There are obvious benefits in aligning OpenJDK projects with the JDK release timelines but there is no rule that this be so.
How should JavaFX evolve? What should be its focus to keep the community’s interest alive?
Johan Vos: It’s mainly up to the community to define what is needed now. Clearly, there are a number of basic requirements: fixing bugs, maintaining compatibility with future Java releases, and more specifically making sure JavaFX leverages new hardware acceleration platforms.
Since there is a large variety of end-applications leveraging JavaFX, it is impossible to create a single JavaFX platform that solves everything for every use case. I see JavaFX as the foundation for other projects, like ControlsFX, Gluon Maps, FlexGanttFX, FXyz that add more specific functionality. JavaFX needs to make sure those third-party projects can leverage the lower-level functionality without having to implement it themselves.
It’s mainly up to the community to define what is needed now.
Jonathan Giles: I think focus on fundamentals is most important. Finding ways for the code to run faster is most important, to enable the software offered by Gluon to operate at even better performance on mobile and embedded systems.
Dirk Lemmermann: There are certain areas that have been identified as weaknesses within JavaFX. Some of the higher level controls need additional features (primarily the TableView control) and there should be new controls that could be considered core UI elements (a widget to enter a time, auto-complete textfield). Also, the media player should support more video codecs out of the box. SVG support in more places is also a topic.
One of the biggest topics, however, is OpenGL support but I think there are some things already in the pipeline. API for a tighter integration with OS services is also high on the list (e.g. Dock icon and menu support on MacOS X, system notifications).
Donald Smith: JavaFX is a mature technology. The focus is likely to be on adding new features that application developers want, and on making sure that JavaFX applications continue to run on as wide a range of platforms as possible.
In the last part of the interview series, our interviewees weigh in on the fact that JavaFX has been decoupled from the JDK, they reveal if (and why) they would choose JavaFX instead of other UI technologies and if there’s a place for JavaFX on desktop, mobile and embedded. Stay tuned!
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.