I’ve just finished rewriting a component of my app that was using Swing and now is using JavaFX, I’ve ended up with a JavaFX component that integrates with the larger swing app. It is a large app and the rewrite took me a while, in the end everything worked fine and I’m glad I did it.
Reasons you might want to do this in your swing app
You might want to rewrite your Swing app and change it to use JavaFX instead, the easiest way is to do this incrementally by changing each component at a time. This requires that you integrate each of the newly changed JavaFX components with the rest of your Swing app.
I’ll summarize why you might want to start rewriting your app from Swing to JavaFX:
- It’s the future
Swing is pretty much dead in the sense that it won’t get any further developments. JavaFX is the new UI toolkit for Java, it is better prepared for the future with things like touch support, 3D, built-in animation support, video and audio playback, etc.
- Probable future support for mobile: Android, IOS…
From what I’ve been seeing, I think it’s pretty much a guarantee that Android, IOS, etc support will be made available, Oracle already has working prototypes of this that they show on public conferences, the only question is when. I think it won’t take that long, probably we’ll see more on this in the next JavaOne, coming up soon.
- It’s solid
JavaFX is a well-designed toolkit with a rapid growing pace, a bright future and a set of good free UI tools. Furthermore unlike in the past, Oracle is giving developers feedback a great importance changing and adapting its APIs to meet their goals.
- It’s pretty
Unlike Swing, not counting third party librarys, which was ugly by itself, JavaFX looks good right from the start. Given that users nowadays expect good looking well designed apps this is a pretty good point.
How you do it
Back on JavaFX 1.3 you could embed Swing in JavaFX but not the other way around, at least not officially. I implemented a Swing component that allowed you to embed JavaFX content in Swing (called JXScene) and made it publicly available in the jfxtras project. It was the only way you could embed a JavaFX scene in a Swing app.
Now Oracle with JavaFX 2.X made an official way of embedding JavaFX in Swing which makes more sense but unfortunately not a way to embed Swing in JavaFX, however I guess this will suffice in most cases.
Arquitecture
Essentially when you are embedding JavaFX in Swing you end up with 2 running UI threads: the Swing EDT thread and the JavaFX User thread.
There is a chance that in the future there will only be one thread for both as is the case with SWT, making Swing run on the JavaFX User Thread, but for now we’ll have to manage our way with 2 threads.
Two threads running at the same time in the UI is what complicates matters, and makes JavaFX integration not as easy as you might expect, unless you’re doing some trivial small app but I guess that is not the scenario for most of the real world use cases. If you’re doing a small app might as well do it all in JavaFX.
Coding
JavaFX gives you JFXPanel, which is a Swing panel that hosts a JavaFX scene. You set the scene on the JFXPanel and add the panel wherever you could add a Swing Component.
To access JavaFX data you have to wrap your code in a Runnable object and call the Platform.runLater method:
jbutton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
Platform.runLater(new Runnable() {
@Override
public void run() {
fxlabel.setText("Swing button clicked!");
}
});
}
});
On the other side is Swing data. This data must be accessed only by the EDT. To ensure that your code is running on the EDT, wrap it into a Runnable object and call the SwingUtilities.invokeLater:
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
//Code to change Swing data.
}
});
Tips
- JavaFX already throws exceptions when you access a JavaFX resource outside the JavaFX User Thread, but bear in mind that this does not happen always. To minimize performance costs not all situations are checked.
- If you use Substance third party library than an exception will also be thrown whenever a Swing resource is accessed outside the EDT. Setting Substance as your Swing look and feel might be a good solution to lessen concurrency mistakes on the swing side that you might do.
- Be very careful when sharing resources between the 2 UI threads, try to avoid this as much as possible. Best way to solve multi-threading problems is to avoid them, and these kind of problems are among the most difficult to solve in Software Engineering. There is a reason why Swing started off as a multi-threaded toolkit and ended changing to a single threaded one.
- Sometimes you might want to check if you are on the JavaFX User Thread via
Platform.isFxApplicationThread() and only than issue a call to Platform.runLater(…), because if you are on the JavaFX User Thread and call runLater(...) the execution of the code that is inside will still be deferred to a later time and this might not be what you want.
Other links to check out:
