Original URL: http://www.theregister.co.uk/2008/12/08/javafx_review/

Gaps blight JavaFX early promise

Sun repeats Swing mistakes

By Matt Stephens

Posted in Developer, 8th December 2008 21:14 GMT

Review After a long wait, JavaFX 1.0 trundled onto the Windows and Mac stage last week and took an awkward bow.

Was it worth the 18 months of audience slow-hand-clapping? Do the results justify Sun Microsystems' apparent diversion of resources away from Swing? Can the finished product compete with the already established Adobe Systems' Flex and Microsoft's Silverlight?

Despite my earlier reservations, this is an encouraging 1.0 release. However, there are enough disappointments in there to curb anyone's enthusiasm. There are also enough gaps in the product and blind spots in Sun's approach that make me seriously concerned that Sun is doomed to repeat the same mistakes it made early on with Swing.

Thankfully, Sun has swept away the abomination that was the early javafx.com website and replaced it with something more presentable. The demos are also improved, but to get a more impressive or heartfelt demo, you have to look beyond Sun and find out what the community have taken a few minutes to knock up, like this nice PAC-MAN clone.

What's it all about?

JavaFX is clearly and primarily a "whizbang" UI toolkit for enriching web pages with interactive content. Built-in graphical effects include Gaussian blur, motion blur, glow, drop shadows, and lighting and transformations such as shearing, rotating, and scaling.

Java integration with the web browser is definitely improving. You can now make calls directly from your applet into JavaScript and vice versa - as long as you have the "LiveConnect API bridge for JavaScript" browser plug-in installed.

Previously, I bemoaned the inability of JavaFX (and Swing) to link in a separate stylesheet to style components at runtime. This was a distinct advantage that Flex had over Sun's offering. It looks like someone at Sun has answered our prayers, though, as the Scene graph has a new stylesheets attribute to use with this scene's contents.

For example, your separate .css file could contain:

"javafx.scene.control.TextBox":focused {
    border-radius: 4;
    font: 16pt Arial-BOLD;
    background-fill:#22252c;
    focus-fill:#22252c;
    highlight-fill: #95a7d8;
    selected-text-fill: white;
}

This feature alone will make JavaFX a much more attractive prospect for web developers wanting to integrate a Java front-end into their websites. It would have been even nicer to have a default mapping between components and their html equivalents so you could just point to the exact same CSS files. Perhaps in the next version?

Still no GUI editor

The NetBeans JavaFX editor feels like it desperately wants to be a WYSIWYG GUI editor: currently you can drag components from a palette and drop them into your source code. For example, dragging and dropping the Timeline element into your code produces the following boilerplate:

Timeline {
    repeatCount: Timeline.INDEFINITE
    keyFrames: [
        KeyFrame {
            time: 1s
            canSkip: true

        }
    ]
}

What they have is nicer than nothing at all, but until a proper GUI editor is available, Adobe has a definite edge over Sun with FlexBuilder. Why Sun didn't gallop out of the stable with a working adaptation of the NetBeans GUI Builder formerly called Matisse, for JavaFX eludes me.

Sun has made much of the product's workflow integration with Adobe Creative Suite 3, so arty types using Photoshop or Illustrator can wrap their creations in a JavaFX-friendly format at the click of a menu option. For anyone concerned by the proprietary nature of this approach, Inkscape integration via a third-party is on its way.

JavaFX Script

The jury's still out on whether JavaFX Script will be the platform's main strength, or a quirky weakness. Its data binding and trigger support is just the coolest thing. Also having the power and maturity of Java and all its libraries behind it is not to be sniffed at.

Many Will Groan

Many will groan, though, at the prospect of having to learn a whole new scripting language that isn't really based on anything. At least starting with the best bits of an existing language like JavaScript would have kept it familiar.

The quirkiness isn't just in the syntax. There are surprising side-effects to the declarative approach. For example, doing this:

var myScene = Scene {

    fill: myGradient

    content: bind stuff

}

 

Stage {

    title: "My Stage"

    width: 450

    height: 450

    scene: myScene

}

Is very different than doing this, which produces a blank window:

Stage {

    title: "My Stage"

    width: 450

    height: 450

    scene: myScene

}

 

var myScene = Scene {

    fill: myGradient

    content: bind stuff

}

This is compile time versus runtime: myScene is compiled in therefore available anywhere in the script, but at runtime, the script elements are executed from top to bottom, not when they're first referenced - except in the case of a timeline function or GUI event.

To me, this breaks the principle of least astonishment. It also raises some thorny questions about the order in which script elements are executed. For example, does the ordering of import statements matter? I can see this leading to insidious runtime issues in big projects where simply swapping two import statements around magically fixes (or further breaks) things.

Whither Swing?

With Sun's new golden child running around, the question is what's the future of Swing? Is it now legacy. Will Sun continue to prioritize it? Swing is highly pervasive, with millions of dollars of investment in projects inside banks and large organizations around the world.

For this important toolkit to be "mothballed" by Sun would be unthinkable (and yet there have been rumblings in that direction). While Sun hasn't categorically asserted that it will continue to develop Swing, your "legacy" Swing components will at least interoperate more or less seamlessly in your JavaFX scene graph.

And of course your Java classes can be called directly as well. JavaFX objects can implement Java interfaces, allowing you to reference them in your Java code - the code need not know that it has an alien entity in its midst.

For companies that decide to take the JavaFX route, this does at least mean that there's a fairly comfortable migration path. And the future of Swing seems fairly secure, at least for now.

Is JavaFX for you?

Regardless of who uses JavaFX, there is the worry that Sun has failed to recognize - or at least target - the real audience here. We're talking Visual Basic refugees and web developers who know a bit of JavaScript and who may be lured into trying JavaFX.

Another potential audience will be Swing refugees worried that their careers are about to hit a dead-end unless they move with the times. Also, there are developers who would like to use Java for a UI but are scared of Swing's complexity.

For any of these people, JavaFX will feel like a major step backwards until that mythical GUI editor is ready.

Then there are Adobe Flex and AIR developers. It's highly unlikely that this group will switch as long as they perceive Sun's offering as inferior. And currently, Flex offers a more compelling all-round platform and set of development tools. It could take a couple more releases for JavaFX to catch up.

The target audience may not be as technical as your standard Java developer. They'll expect a high level of integration, point and click development, and an easy way to download and install new UI components. Swing never had such a thing, and a third-party component market never emerged in the same way that it did for Visual Basic or Delphi.

Here's Sun's chance to get it right second time around: to create a searchable online marketplace with point-and-click install of third-party libraries and widgets. A component ecosystem. Once again, Sun is leaving this vital aspect of the product to pure chance, no doubt hoping that a charitable third-party somewhere will handle this for them.

For a 1.0 offering, there are some noticeable gaps. JavaFX for mobile is still nowhere in sight, there's still no GUI editor of course, and the Linux version isn't even appearing in the nightly builds yet.

But despite these concerns, the platform should have a bright future - as long as Sun can plug the gaps and bring the next update to market significantly faster than 1.0.

Matt Stephens co-authored Use Case Driven Object Modeling with UML: Theory and Practice, which illustrates how to create the ideal software design with Enterprise Architect, Spring Framework and JUnit.