The cutting edge of JavaFX
In his article " JavaFX 8 - What's New? " Hendrik Ebbers describes the latest features bundled into JavaFX. Hendrik, who regularly blogs on his website guigarage.com about architectural approaches for JavaFX, is the author of various open source projects such as AquaFX and DataFX and is currently preparing a book titled "Mastering JavaFX Controls 8", scheduled for release in the summer. In this interview (also featured in the upcoming issue of JAX Magazine), he assesses just how production ready JavaFX is in its current state, how JavaFX compares to Swing, and what the chances are that JavaFX will lead to a renaissance of Java on the desktop, or even a boom in Mobile/IoT- Devices.
JAX: In your article " JavaFX 8 - What 's New" you say that version 8 of JavaFX is ready for production use. How did arrive at this conclusion?
Ebbers: I know some companies / developers who had already successfully implemented projects with JavaFX. One example is the eteoBoard. From all these people I have gotten mostly positive feedback about JavaFX. Of course, one should not forget that there will certainly still be a few minor bugs and open issues with JavaFX 8. But what framework can claim to be entirely bug-free?
Does that mean that JavaFX as an UI Kit is already equal to Swing or has even made it obsolete?
That depends entirely on the approach and the application scenarios. In many ways, JavaFX is miles ahead of Swing: Features such as the property API of JavaFX do not exist in this form in Swing. Also components like the WebView can not be easily realized for Swing. In addition, JavaFX has a much more modern API and simply offers many more possibilities on a basic level.
You simply have to think about the time that Swing was realized. At this point, nobody cared for animations or blur effects in a UI. In order to program them for Swing it requires a lot of know-how and a lot of code. Anyone who has ever tried to program complex effects for Swing or has read the book “Filthy Rich Clients” knows what I'm talking about. On the other hand, many interesting libraries for Swing have emerged over time. The JGoodies Forms layout was for me, for example, for several years the standard when it came to the layout of application screens.
In addition, Swing offers " system look and feel " to make applications look native on the respective OS. This does not yet exist for JavaFX to date. Out of the box it includes the two cross-platform themes " Modena " and "Caspian ". Although Modena looks pretty cool, you always realize that it is a JavaFX application, and there is a certain friction between the OS and the application.
Luckily, there are already attempts by the community to solve these issues. With AquaFX for example, there is already an open source theme for JavaFX 8, which mimics the native look and feel of Mac OS. In addition to this project, there are already a number of first-class open source projects for JavaFX . Examples I could name are DataFX , Open Dolphin and ControlsFX . And this is exactly why I think that JavaFX, in the areas where it hasn’t perhaps yet currently superseded Swing, will follow within a short time. The community around JavaFX is extremely active, and Oracle will continue to assist these people.
As we know, JavaFX provides some tools for migrating from Swing to JavaFX - for example SwingNode . How would you evaluate the effort to migrate from a Swing application to JavaFX ?
The tools mentioned are very well suited to ensure a smooth migration. During this process individual components of a Swing application will be gradually replaced by JavaFX.
You can choose which approach to take: either integrate JavaFX into Swing or vice versa. However, in this procedure there are a few factors that must be considered: as already mentioned, there are no native themes for JavaFX and no themes that correspond to the UI Cross-Platform Look & Feel of Swin . Therefore, there will always be a kind of fraction in the UI, as long as one does not develop your own theme.
In addition, it certainly depends on the basic architecture of the swing application how complicated migration really is. My knowledge in this area, however, is so far only theoretical, as I have yet to make my first migration of a larger application. So far I've only created a few prototypes for articles, lectures and my JavaFX 8- book.
JavaFX as part of Java 8 can be found in both the JDK and JRE. In your opinion, how will this affect the user opinion on JavaFX? Will we see a JavaFX boom which makes Java attractive again, beyond the server applications?
In any case it is clear that Java 8 is really only the start of JavaFX. Because of the fact that it is now an integral part of the JDK and JRE, there are now no longer any barriers to using it. In the near future developers are certainly more likely to use JavaFX for the creation of desktop clients than Swing.
Whether there will be a JavaFX boom, no one can say today. I think JavaFX has laid the basic foundations. Whether Java will become more interesting again on the desktop certainly depends on many other factors. Because of App stores, it has become interesting again to develop native desktop apps in recent years. Operating systems like Windows are quite clearly still in their infancy, and it is exciting to see how these technologies develop further.
The near future will show if Java applications can also grab a piece of the pie. In addition to desktop applications, use of JavaFX for mobile and embedded devices is certainly very interesting. The images on the Raspberry Pi are now shipped with Java, and early versions of JavaFX are also available for Android / iOS.
Because of mobile usage, very interesting synergies arise when developers just need to create different views for a desktop and mobile client and can use the remaining part of an application on all devices.
You write that JavaFX 8 is already fully adapted to lambdas . What does this mean for users of Java 6 and 7?
This question I would not necessarily refer to as concerning JavaFX. Because of Java 8, lambdas are now an integral part of the language, and every developer should try to get familiar with them as quickly as possible.
Even today lambdas are being used in the first frameworks, and it will surely not be long before they are found everywhere. We’ve seen similar developments in the past: no Java developer would nowadays want to miss out on generics, for instance.
Of course you can also do without using lambda expressions and only work with anonymous classes when working with JavaFX. However, since JavaFX already defines many functional interfaces, very soon boilerplate code will develop. One can compare the situation with the Stream API of Java 8: theoretically you can also work with anonymous classes - but who wants that?
How good is the current tooling for JavaFX, ie. Scene Builder, NetBeans, Eclipse, IntelliJ, etc?
Very good! With Scene Builder and Scenic View, you have two excellent tools for developing JavaFX applications right out of the box. Scene Builder especially is getting better and today I do not want to miss the tool dialog layout creation.
In the current version of the APIs of Scene Builders are prepared for the integration into IDEs. Especially with NetBeans there happened a lot in the last few days. For Eclipse , there is the “e(fx)clipse project”, which takes care of the integration of JavaFX into Eclipse.
IntelliJ also has a JavaFX integration already, for example CSS editor. Even with all theses tools and IDEs, of course there is still clearly room for improvement, and Scene Builder isn’t integrated into any one of these IDEs 100 %. However, one can also work with JavaFX easily without an IDE integration, since it is plain Java. Thus, each tool and every bit of support is clearly an advantage over other UI frameworks.
What do you like most about JavaFX 8?
Oh, that's a difficult question. I think the coolest API of JavaFX is the Property API. When I'm not working in a JavaFX Environment, I always miss the bindings.
Another very clear advantage is the CSS integration. At first, I approached the subject with a certain scepticism. But once you have styled the first components with CSS, you can see the added value.
Finally, I would give FXML as an example. In combination with CSS you can really manage to differentiate the UI, i.e layout and skin, completely from the business logic implemented in Java.
Are there still weaknesses that you would like to see corrected in future versions ?
I think that some additional components would be quite interesting. As the chief developer of JavaFX Controls is also responsible for ControlsFX , I think that some will be taken care of in JavaFX 9.
There are some classes that are still currently in private packages and didn’t manage to become public 8 in time for the release of Java 8. Especially when you develop your own components, you have to make a few compromises here, if you do not want to work against private APIs.
Moreover, I think the ability to expand is lacking in a few places . So, even if you can create your own CSS properties and also define parsers for new CSS values , you cannot extend the existing ones. Also at the support for themes should be expanded.
On the other side, the creation of System -Themes should be better supported. Additionally, it is currently not possible to easily create extensions for themes. That said, I am still very satisfied with the current version of JavaFX.