JavaFX 2, a Completely New Client Layer for the JavaSE Platform, Now in Public Beta
The first public beta of JavaFX 2.0, Oracle's Java orientated rich client platform, is available for download, along with a beta plug-in for NetBeans 7.
The release includes:
- Java APIs for JavaFX, which are a continuation of the JavaFX 1.0 product line.
- A new graphics stack comprising a graphics engine (Prism), coupled with a new windowing toolkit, called Glass, which acts as the platform-dependent layer that connects the JavaFX platform to the native operating system. Prism supports hardware acceleration on a wide variety of cards from NVIDIA, ATI and Intel, which in turn uses different rendering paths depending on the platform being used (DirectX on Windows, OpenGL on Mac, Linux, and embedded). When hardware acceleration is not possible, Prism uses the old Java 2D renderer.
- A media engine that supports playback of web multimedia content based on the GStreamer framework. The media engine supports the playback of MP3, AIFF, and WAV audio files; and the playback of Flash (FLV) video files comprising VP6 video and MP3 audio.
- A web component that uses WebKit to render HTML, with hardware accelerated rendering using Prism.
- An updated browser plugin that allows the loading of JavaFX applets based on Prism.
- A new set of UI controls such as Charts, Tables, Menus and Panes, all of which can be skinned using CSS.
The beta also includes a small selection of samples, including Ensemble, which is the main sampler for JavaFX.
The first release of JavaFX 2 will be on Windows only, although architecturally the system has clearly been designed to be cross-platform, and Oracle has made it clear that it intends JavaFX to be multiple-platform:
We absolutely will be targeting a whole host of different platforms, not even just the big three (Mac, Linux, Windows). The value of the Java platform is in the fact that you can write across multiple operating systems and devices.
Whilst both Flex and Silverlight use XML as their declarative language (MXML and XAML respectively), JavaFX originally included a new DSL, JavaFX Script, for the task. JavaFX Script, whilst interesting, was seen by many developers as a barrier to entry, and Oracle announced last year that whilst it would continue to invest in the JavaFX platform, it was discontinuing work on it. An XML-based declarative language (currently called FXML), is in the works, but has not yet made it into the beta.
The lack of JavaFX Script does make the API feel more verbose, but the change isn't as dramatic as it might have been. For one thing, the javafx.builders package offers 257 builders, covering all the APIs. In addition Lambda support in Java 8 will make a significant difference. Richard Bair, the architect for client software at Oracle, previously told InfoQ
JavaFX was designed to be amenable to the "lambda" language feature planned for Java SE 8. The current plans and proposals for lambdas favor "single abstract method" interfaces. We have designed the new Java APIs in JavaFX to follow this pattern so that when lambdas become available, they will be natural to use with the JavaFX 2.0 APIs.
JavaFX 2 represents a major update to the client-side Java stack, offering an alternative to the entire client layer of the JavaSE platform. Osvaldo Pinali Doederlein has gone as far as to argue that
JavaSE as we know it is deprecated. I wonder how many people realize this; if you don't, check again Cindy Castillo's great overview of the JavaFX Architecture. It's not just a new library of components, animation and rich media. It's something that completely replaces AWT [Abstract Window Toolkit], Java2D, Swing, Java Sound, Applets, ImageIO, Accessibility - in short, the entire Client layer of the JavaSE platform. (No, a JavaFX "applet" doesn't use the java.applet API anymore.) Oracle got rid of the massive legacy of the AWT and everything that was built on top of the AWT; that's the major reason why the new browser plugin is much better.
Amy Fowler, a Senior Staff Engineer at Sun Microsystems, and one of the founding members of the Java Swing GUI Toolkit, suggests that such a change is necessary for Java to be a viable client platform:
User-interface technology is on a collision course with graphics. For Java to be a viable client platform in the long haul, it must be inherently capable of the sort of visual delicacies that you see in iPhone/iPad applications. As I've stated many times, it's possible to achieve some of this using Java2D tricks in Swing (e.g. Kirill's very nice Trident library), but it requires sophisticated gymnastics; it’s not a natural fit. The crux of the problem is that Swing is rooted in the antiquated AWT, rather than being integrated into the 2D coordinate system. Fixing this would require some massively incompatible changes and once you march down that path, well, you start asking yourself what other incompatible improvements should be made ….pretty soon the remodel becomes reconstruction and you realize that a new foundation is really needed.
Whilst the RIA space, which Adobe has dominated with Flash for so long, looks to be shifting towards HTML 5 and related technologies, the extensive use of native applications on the current generation of smartphones and tables demonstrates that there is still a role for non-web-based applications. Oracle, of course, makes heavy use of Java and Swing in its own desktop applications, and the JavaFX 2.0 investment will ultimately give it a Swing 2.0 platform to develop with.
A tool for Oracle but nobody else cares
That said (and no matter how verbose xml-based markup is), it does make sense from a designers perspective to move away from JavaFX script and to xml.