Gaps blight JavaFX early promise

Sun repeats Swing mistakes

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.