Is HTML5 a common platform for rich Internet applications, or a common toolkit for building rich applications on varying platforms? Oracle's response to that question came yesterday, and in typical Larry Ellison fashion, it essentially boiled down to, "We don't give a rip."

When Sun Microsystems produced the first go-round of JavaFX in December 2008, its aim was to build and promote an entirely new declarative language - not Java, not JavaScript - for describing the front-end UI of a distributed app. What developers needed at that time was a simpler, programmatic way to approach the contents of UIs. CSS looked under-developed, and although Microsoft's approach (XAML) was certainly thorough, it lacked the more conservative, procedural approach that veteran programmers were accustomed to.

That was then. Amid a completely different landscape, Oracle yesterday has remade Sun's JavaFX distributed apps platform into a version 2.0 with fundamental differences from its predecessor. The most prominent addition is a new Oracle language called FXML that's very different from JavaFX Script in its handling of UI elements, but whose distinctions against XAML seem almost artificial.

"One of the advantages of FXML is that it is based on XML and is familiar to most developers, especially Web developers and developers using other RIA platforms," reads new JavaFX 2.0 documentation finalized yesterday. "Another advantage is that FXML is not a compiled language; you do not need to recompile the code to see the changes you make. A third advantage is that FXML makes it easy to see the structure of your application's scene graph. This, in turn, makes it easier to collaborate on user interfaces among the members of your development team."

The notable and notational differences

JavaFX, it's very important to note, is not Java. While JavaFX Script maintained the straightforwardness of Java, it also maintained the same context. That meant recompiling the app - or at least, recompiling the script - whenever the front end required changing. In version 2.0, Oracle has cast out the declarative-like portion of JavaFX Script (which lives on in an open source project called Visage), replacing it with FXML and adapting the remaining elements of JavaFX to load that FXML as separate resources.

The difference in methods between JavaFX Script (Visage) and FXML is the difference between procedural and declarative languages. A procedural language gives instructions on how to build something, as if they were being told to someone else - or rather, as if a professor were giving instructions to his math students. "Assume there's an object in space, and we don't know what it is yet, but let's call it 'Frank,'" says the procedural language. "Let's instantiate Frank as a new member of the 'Box' class. Within that class is another new object whose class is inherited, called 'Button.'" By stark contrast, a declarative language states where things are as though they already existed. "Beginning of box," it starts, without having to name it "Frank" or anything else first. "Inside the box, beginning of button. Button says, 'Send.' Reacts to being pressed. End of button."

Now with one less letter!

JavaFX remains a declarative language, and its programs remain constructed using IDEs like NetBeans, which are also used for Java apps. In fact, you build Java apps that utilize JavaFX front ends using the same environment (more on that later). But the FXML-based front end for JavaFX 2.0 apps is described in a separate file, and referenced in the JavaFX code using a handful of interwoven methods. The .getResource method points to the main FXML layout file, and the .getBundle method points to a separate properties file that may contain variations on the main theme. The .getClass method produces the JavaFX 2.0 equivalent of the front end (the "stage," in Sun's original parlance) had it been written directly into the script. All three methods are supplied as arguments for the .load method that instantiates an object from external resources.

The syntax of an FXML file follows the "begins-here/ends-here" logic that typifies XML. Here's an example from Oracle's documentation, which creates an on-screen box that other objects are designed to stack on top of:

<StackPane>
<children>
<ImageView>
<image>
<Image url="@fx_boxback.jpg"/>
</image>
</ImageView>
<Label text="%loginExample" style="-fx-font: NORMAL 20 Tahoma;"/>
</children>
</StackPane>

It's constructions like this one that should have XAML veterans raising an eyebrow. For Silverlight, the class of on-screen box with essentially the same purpose is StackPanel, with an "l". What Silverlight calls a "canvas," JavaFX calls a "stage." And there are plenty more semantics-only differences where that came from.

Another new JavaFX 2.0 feature - which we're told remains forthcoming - is the ability to instantiate JavaFX apps in their entirety (rather than load them separately) through Java, by way of a new API.