Time up for Oracle's HTML5 killer?
Message to Ellison: no more JavaFX reboots
Changing times, terrible tools
Central to the new architecture is the Scene Graph, which is comparable to the browser DOM; even to the extent that CSS styles can be used to apply styles and layout rules. In fact CSS support is a particular strength in this new release.
There's a set of modern new components that look pleasing in their default configuration, so you won't sweat to make your app not look horrible (a criticism that was commonly levelled against earlier versions of Swing). Naturally, the components look nothing like the underlying OS, but then nothing does these days (least of all the OS itself, paradoxically), so that's really not a problem.
Also new is a browser component that renders HTML using WebKit - a welcome addition.
The oddball JavaFXScript, which had all the grace of a drunken gazelle in JavaFX 1.0, has been dropped in favour of pure Java combined with a Flex-alike declarative "layouting" language, FXML. The idea is to split the UI definition from the behaviour, and to make GUI tooling support easier.
FXML is a first step in the right direction, but it has a long journey ahead. Community developers are stepping up to supply the missing pieces such as Dependency Injection (DI), which will make unit testing far easier, but this stuff should be there out of the box. Same goes for linking the spanky new components up with data sources. Oracle can thank their lucky stars for a patient and enthusiastic community.
No help: Code completion in NetBeans' FXML editor
The examples - a separate download from the main SDK - are kind of nice, but are not on par with Adobe's Tour De Flex, and font rendering is rough. Bizarrely, given the amount of noise behind the new FXML, the source for the examples is almost all in Java: very little FXML to be seen.
Initially, Oracle is only supporting the latest beta of old-men's-club IDE, NetBeans. Oracle's strange infatuation with NetBeans at the expense of Eclipse and IntelliJ might hinder JavaFX's adoption.
The decision appears even odder when you consider that Composer, NetBeans' visual GUI designer, is taking an extended pit-stop while it's being rewritten. This means we're back in the surreal position of having Java's premiere GUI platform without a GUI editor.
It's a clear sign that Oracle still doesn't get that application development is all about providing quality tools, much less about the platform. The editor can't be an afterthought: it has to be the centre of their universe, with all development efforts spreading out from it.
JavaFX programs can still be developed in your IDE of choice: just link in the external jfxrt.jar like any other library. But you just won't get the linked-up editor support that you'd reasonably expect. For a more integrated experience, do check out Austrian developer Tom Schindl's flowering Eclipse plug-in, e(fx)clipse (although if I'm honest, Schindl's proprietary DSL, FXGraph, may limit its appeal).
Code completion in NetBeans' FXML editor is nonexistent. That "No suggestions" popup follows you around like a crap genie.
Refactoring support is also lacking. Here’s an FXML element describing a column in a table:
<TableColumn text="Instrument" fx:id="instrumentCol" />
You can link this to a Java field via the @FXML annotation:
@FXML TableColumn instrumentCol;
But if you use Ctrl+R to rename the field then you'd also expect the element's fx:id attribute to be renamed. No such luck. To make matters worse, there's no compile-time safety. The botched refactoring would not be caught by the compiler; instead at runtime you get a cryptic NullPointerException, which beginner developers are going to love. If the mismatch is between the Java field and the data class's corresponding property, there's not even an error: the code just fails silently and doesn't populate the table cell.
Lucky then that JavaFX has such amazing, comprehensive support for a unit testing safety net? Ah. Yes.
The lack of documentation on unit or acceptance testing suggests that it's not even an afterthought, but that Oracle hasn't even thought about it. There's no easy way to instantiate a partial Scene Graph for isolated testing. Sure it may be possible, but it isn't easy. In an age where developers are increasingly savvy to the need for unit tests, this stark avoidance of the subject by Oracle is perplexing to say the least.