JavaFX 13 release interview with Johan Vos

Yes, today is a truly exciting day for Java enthusiasts. We have not one, but two releases expected! We’re excited for Jakarta EE 8 as well, but for now let’s concentrate on JavaFX 13. So with no further ado, let’s get down to celebrating JavaFX 13 with Johan Vos!

JAXenter: JavaFX 13, or OpenJFX 13, is going to be released on September 10th. Can you give a little insight on what this release will have in store for developers?

Johan Vos: We’re continuing the development that we started with the new release cycle. That means we work on bugs and features, and when they are ready to be included in a release, we include them.

JavaFX 13 contains 97 bug fixes and new features, in the different subcomponents. Controls and layout issues are fixed, the WebView and underlying webkit implementation is updated, the build system has been improved, and a new API is added allowing to more easily integrate native content generated by third party applications.

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

Johan Vos: Probably the most relevant change in JavaFX 13 is JDK-8167148, which adds support for rendering native third-party content. This is a feature that has been requested by JavaFX developers for a very long time. It’s a tricky thing to do though, as it is hard to do it right without breaking the cross-platform implementation compatibility of the JavaFX API’s. Following the general OpenJDK guidelines, we prefer not to be too intrusive while preserving backward compatibility. On the other hand, it would be less than ideal if developers had to implement platform-dependent code in their own application.

The way it is handled in JavaFX 13 doesn’t break any backward compatibility, removes the risk on platform-specific behavior, and provides a good basis for developers to add functionality on top of it.

We had this feature in early-access releases, and it has been discussed intensively on the mailing list and especially in the github issue tracker. Many developers who requested the issue already experimented with the new API.

SEE ALSO: OpenJFX 13 – “JavaFX gets its own identity”

JAXenter: This is the second release under the new release schedule, what are your thoughts on this? Is the “half year per update” approach reasonable or will the schedule eventually change to a quarterly or yearly release?

Johan Vos: It creates some overhead as we are providing update releases for JavaFX 12 while at the same time providing early access releases for JavaFX 13, and working on JavaFX 14. For Gluon, it’s even more complicated as we also support JavaFX 11, hence we are working on 4 different versions simultaneously.

However, the tools are now in place to automate this as much as possible, including automated testing and building. For OpenJFX developers, this release schedule means less stress, since if their feature doesn’t make it for a specific release, there is not much lost as they get a new chance in 6 months.

For the JavaFX developers (the ones using JavaFX API’s), it means smoother updates. If there is 4 years between 2 major revisions, chances are high that companies don’t want to upgrade immediately, and the cost of updating can become very high. By having faster releases, it’s easier for developers and companies to keep using the latest versions without worrying about huge changes.

From an expectation management point, it’s important to stress that we continue working at the same pace as before. We don’t want to lower the quality bar in order to rush more features in. But developers understand that in 6 months time, there can be less big changes/features in a release than in 4 years time.

JAXenter: JavaFX is not part of the official JDK release anymore for quite some time now. Did this have a positive or negative effect?

Johan Vos: More and more developers are now very comfortable with the fact that JavaFX is a separate download, either via an SDK or via artifacts in Maven Central. We can see the positive effects already: the native rendering addition has been integrated early in the process in JavaFX 13 early access builds, so that we could get feedback from developers.

Download statistics and replies from developers show that those ea-builds are very often used, especially via Maven Central. It’s indeed very easy for a developer to simply change the version of the JavaFX dependencies in his pom.xml or build.gradle from e.g. 12.0.2 to 13-ea+12. There is no reason for a new manual download just to test this single feature.

SEE ALSO: OpenJFX to follow Java and migrate to GitHub

JAXenter: Next up is JavaFX 14, any major changes planned for this release or the near future?

Johan Vos: It’s really up to the OpenJFX developers to define the shape of the next release. With Gluon, for example, we listen to our customers. If our JavaFX 11 LTS customers want more focus on a specific area, we work on that. After all, these customers pay the engineers working on OpenJFX, so they get a big influence on the roadmap.

One of the things I’m working on is on improving the build system for more cross-platform support. We want to get to the point where we can use 100% of the OpenJFX code to build JavaFX for iOS, Android and embedded ARM (32 and 64 bit) devices. We want JavaFX to work on more platforms than the current ones.

In the OpenJDK team, work is being done for supporting Metal. We’ll investigate how that work can be leveraged in OpenJFX.

Thanks very much for talking to us!

The post JavaFX 13 release interview with Johan Vos appeared first on JAXenter.