JavaFX 2 — The new Swing ? (!)
October 11, 2011 16 Comments
JavaFX 2 has been released a couple of days ago. Of course, as a long time Swing hacker, I was curious if it would deliver what was promised, no more than becoming the next generation Swing. So here is a quick analysis based on some playing around with demos, tutorials and studying the documentation:
- First of all, it is Java. Not that aweful JavaFXScript thing that plagued JavaFX1. JavaFX 2 is just yet another Java API. This is important because it allows businesses to preserve their investments into Java technology. JavaFX comes as a JAR file that you include in your classpath like any other extension library. Just like Swing should have been. I just hope they keep it that way (i.e. modular) instead of including it in SE and inevitably creating crossdependencies. Since JavaFXScript is just one of the many languages supported by the JVM, you can still use it to write JavaFX app, but more interestingly you can use Scala, Groovy or whatever is the current hip JVM language. Ah, and the API is not based on AWT or Swing or any other legacy thing (one of the biggest factors that eventually hindered Swing from going forward).
- JavaFX scenes can be integrated into Swing apps. I haven’t tried how well this works, but generally speaking that’s a huge plus. It provides a migration path for corporations to gradually move their apps to JavaFX. Unfortunately the opposite – embedding Swing panels in JavaFX apps – has been dropped. That could become a migration hurdle. Corps often have specialized Swing components that would take months or more to rewrite in JavaFX.
- What used to be the Swing Look and Feels can now be done with CSS (at least most of it). I never understood why Sun invented their own funny XML format for this (the Synth L&F) when there is CSS already widely used. Using this, a corporate design that is used for webpages etc can easily be adopted to Java apps. The default skin looks reasonably pleasing (I’d say it’s a copy of a popular UI toolkit of a computer brand that’s inspired by fruits). I don’t really understand the reasoning to not look like the underlying platform though. Swing made this mistake, now JavaFX does it again. This means Java will keep looking alien. But at least better than Swing ;-)
- JavaFX has a real browser component based on webkit. How long have we been waiting for that! Nothing to add.
- The threading model seems to be similar to Swing: all UI interactions must be done on one thread, the EDT or however it is called in JavaFX. There are small differences, for example you may manipulate inactive components (those who are not linked to any live scene) in different threads. The API also sports an invokeLater() alike (Platform.runLater() ) method, but no invokeAndWait(). I think that’s good because invokeAndWait() was horribly deadlock prone. There also comes a worker API similar to SwingWorker, but more powerful from the looks of it. The EventQueue is not publicly accessible. I think that’s good, there was far too many public APIs in Swing with which people could screw up all the world.
- UIs can not only be written in Java but also in an XML format FXXML and loaded at runtime. This will finally solve my single biggest complaint with the Netbeans GUI builder, that it’s generating both a .form file and the corresponding Java code, which of course tends to get out of sync, especially when people on the same team use a different IDE. I never understood why Netbeans does that though, why not simply load the .form file at runtime? Good they fixed this.
- The drawing and animation capabilities are really impressive. It doesn’t take much to implement fairly complex graphics with all sorts of effects and animations. And it doesn’t take messing about with paint() methods and threads and the EDT to get even the simplest animation to do something, not even talking about doing it correctly. Very nice.
- JavaFX includes support for charts. While this is a nice touch, I also find this a little odd. I would have been glad with a very core-ish API that is JavaFX and extension packages like JFreeChart and friends to provide extensions for specific purposes. If I were to write a game in JavaFX I don’t need charts. But that’s just a minor nitpick.
- My biggest complaint is, of course, that it is not free/open source software yet and not yet available for Linux or anything else than Windows for that matter. Last thing I heard was end of 2012 (!!) for that to happen. WTF is that?? JavaFX is already late in the game, it might actually be too late already, so I cannot understand why they don’t simply put it out for the community to help? There are experienced developers out there (including me and others I know) that would be glad to make it happen earlier. Oracle do you hear that? Free manpower! ;-) Of course, you still need to learn how to deal with that thing called community…
So.. overall I am very impressed. It seems like since a long time, Oracle is getting client side Java right. The basics are all there and all good. Some implementation details are not yet perfect, but hey… that’s a .0 release. If Oracle now gets the remaining parts right, most importantly, learns how to do this community dance, and actually open sources it very soon (developers will love it twice as much just because of it), this could actually get Java a foot in the client market again. It comes quite late, and it might actually be too late already, but there’s hoping…