Original URL: http://www.theregister.co.uk/2008/06/12/javafx_review_part_one/

Sun to lose lunch money on JavaFX

Opens wallet to tough kids

By Matt Stephens

Posted in Developer, 12th June 2008 17:19 GMT

JavaFX, part 1 The Rich Internet Application (RIA) fight is hotting up. And, while Adobe Systems and Microsoft are squaring up in the schoolyard with all the kids cheering and screaming them on, it looks as if Sun Microsystems is in danger of getting its lunch money stolen again.

Sun's offering in the RIA space is JavaFX. Supposedly it will be in competition with Adobe's Flex, which sits on top of Flash in the browser or the Adobe Integrated Runtime (AIR), and Microsoft's "don't close the bar yet, I've just got here!" contender Silverlight.

Much has been said and written about AIR and Silverlight, probably because they are being driven by companies squarely focussed on software rather than a hardware vendor prancing about in software drag. Outside of JavaOne 2007 and 2008, Sun hasn't really talked much about JavaFX. Yet Sun's got some big hopes for JavaFX and the language certainly has some plusses. I thought it was about time to look at what Sun's offering.

First, some context. Sun has a track record of taking years to make anything ready for primetime. Jokes about Java's supposed slowness still appear on Slashdot, dating back to the first few versions from well over a decade ago. It arguably took Swing ten years to become a viable toolkit for creating smart, responsive User Interfaces (UIs). Java Server Faces (JSF) may be reaching an acceptable level of maturity now, but there are very few devotees left to notice.

JavaFX is showing a similar "slow-gro" pattern of development. Of course, it's all very new and pre-release right now. It's a mark of its potential, and possibly even the genuine need for a new RIA platform based on Java, that there's some buzz already surrounding it. The end users may be ambivalent (they don't care how your rich UI works, as long as it works well), but it's safe to say that developers want JavaFX. It's highly anticipated.

Lost opportunities

JavaFX, though, is coming to market with Sun's usual poor focus on supporting resources, while its taken at least one step that'll help set back the cause of adoption. The only book in English on the subject is already obsolete, as Sun in its wisdom made a late change to the syntax. It's a gamble as to whether any documentation, "how-to" blogs or other advice you find on line will use the new syntax.

But what of the language, itself? It's a story of potential and lost opportunity.

JavaFX is a great idea: put a syntactically sweet layer on the Java Virtual Machine (JVM), make the saccharin new language a mix of declarative statements for defining UI layouts, and procedural/imperative control statements, and let the web designers go wild. It has the potential to own the web.

The new language has at least one major plus point. Swing components and their attributes are hidden inside pretty declarative wrapping, so the SimpleLabel tag wraps a Swing JLabel, TextField wraps a JTextField, and so on. JavaFX code compiles down to Java bytecode and co-exists with Java very easily.

Unfortunately, this area doesn't win a gold star due to what appears to be lazy grammar coding. The parser doesn't understand context too well, so keywords such as "insert" must be escaped, as in this example from the Planet JFX site I linked to earlier:

import javax.swing.JTextArea;

var textArea = new JTextArea();
textArea.<<insert>>("Hello", 0);

There are other plus points, though. These include the first-class functions for callbacks (which compile down to anonymous inner classes) and expression-based binding of GUI elements to dynamic/calculated values. The ease with which you can bind UI components to a database back-end is just awesome.

The decision to use a nice, clean JSON-like declarative syntax instead of XML was a brave one, but a good one. It means your scripts will actually be readable (which is lucky given the current lack of decent tool support).

Declarative does not have to automatically mean XML. However, there's no reason why there shouldn't also be an exactly interchangeable XML dialect.

For example:

import javafx.ui.*;

Frame {
  title: "Die, Ajax! - Hello World"
  visible: true

Is the same as:

  <frame title="Die, Ajax! - Hello World" visible="true" />


This interoperability would make it easier for XML tools to produce and consume .fx files, which would be a good thing for obvious reasons.

JSP has this capability and HTML of course has XHTML. Flex and Silverlight, meanwhile, go the other way and only use XML (MXML and XAML respectively). Not having an XML dialect is just really stupid - there's no other word for it. It's as if the last decade of XML development never happened.

Given that JavaFX is denied access to the world of XML tools, which might have helped those interested in using the language, you would hope that its home-grown tools support is therefore second to none. But it isn't.

I'll tackle the JavaFX tools market - and how this may affect the technology's chances in the highly competitive RIA field - next time.®

Matt Stephens is co-author of Use Case Driven Object Modeling with UML: Theory and Practice, which illustrates how to get from use cases to source code and tests, using Spring Framework, JUnit and Enterprise Architect.