This article is more than 1 year old
Time up for Oracle's HTML5 killer?
Message to Ellison: no more JavaFX reboots
Time to build
The reboot of JavaFX has produced what might politely be termed a "version 1.0 API". Simple errors are rewarded with quite scary and obtuse exceptions. Seemingly simple tasks (such as finding a component without having to linearly traverse the whole scene) are difficult and require some heavy lifting from the community to plug the gaps left by Oracle.
I'm sure the API will mature and grow over time, but at the moment certain tasks that should be simple turn into a gruelling hunt for examples. It is as if the JavaFX designers have launched into the stratosphere, wanking over how cool all the advanced stuff is, while forgetting to make the simple stuff simple.
TableView's data model is an ObservableList, a new Collections class unique to JavaFX. An ObservableList fires off events any time its elements are added or removed. This allows the TableView to automatically refresh any time the data changes. But does this approach scale?
I set out to write a tester app that would pummel TableView with "live" updates, to see if the UI remains responsive. The use case was to have a table with 10,000 rows and 1000s of real-time updates per second. My first try was deliberately naïve: after populating the table, it then flung a randomly updated row at the table's ObservableList, 1000 times a second. Obviously a real app wouldn't do this. It would pool the updates, throw away the stale deltas, and unleash batched updates at a less frenzied rate.
Nevertheless, the table coped surprisingly well: the UI remained responsive throughout. The same approach with a Swing JTable would have locked up the whole app. It pretty much made my second test obsolete, which was to send batch updates every half-second at the table. TableView's innate ability to cope with high-frequency updates could turn out to be the platform's saving grace, and a reason for companies with low-latency requirements to adopt it.
The word "integration" can be applied only charitably in this case of Swing and JavaFX. Co-existence would be a better description. While a JavaFX Scene Graph can be added into a Swing container, making them play nicely together can get hacky. Both toolkits follow a single-threaded UI model. However, they use different threads for the same purpose: Swing uses Event Despatch Thread (EDT), while JavaFX introduces the User thread. Programmers will end up hopping back and forth between these two threads in a sword-hopping Highland Fling: inevitably there will be some cut feet in any non-trivial applications.
The reverse situation, adding Swing components into a Scene Graph, was dropped from this release, although the community is trying hard to produce an interim solution.
It may not sound like it, but I'm rooting for JavaFX: I want it to do well. And I'm sure that over time it'll mature into something wonderful so long as Oracle doesn't drop it as Microsoft and Adobe have dropped Silverlight and Flex/Flash.
But progress is woefully slow. The lack of a GUI editor indicates NetBeans has slipped back to its contented, cud-chewing ways, while Adobe pushes ahead with HTML5-based interaction tools; and Flex, as long as it's with us, has a sublime visual editor - which it's had since 2006. Meanwhile, Flex is already multi-platform and can be deployed on iPhone and Android.
JavaFX needs a strong signal from Oracle that they're going to continue to back it, or make it somehow more relevant to the HTML5 age. Just, please, no more reboots. ®
Matt Stephens is a Java consultant in Central London. He recently launched a travel writing site, founded independent book publisher Fingerpress, and co-authored Design Driven Testing: Test Smarter, Not Harder.