JavaFX 1.0 considered
JavaFX 1.0 is finally out of the gate. There are probably many Java engineers and architects who are trying to figure out this technology and see how it could apply to their existing projects. Here is my assessment. Note this applies to JavaFX 1.0.
JavaFX 1.0 is not ready as a Flash replacement in public-facing projects
While slow start-up time has been largely addressed by JRE 1.6 update 10, it is not widely deployed (3.7%). For some strange reason, my machines would not install JRE 1.6u10 until JRE1.6u7 has been installed. Perhaps Sun engineers could explain why?
The runtime is still heavyweight. When the applet starts up initially, my development machine – which had Netbeans loaded – started thrashing the HDD, and the browser’s message loop was tied up for about 10 seconds. On lesser equipment, running JavaFX applets will be a distinct negative experience.
Furthermore, the new (applet) browser plug-in only works on FireFox 3 and Internet Explorer. There has been reports of browser instability, especially on the Mac.
JavaFX 1.0 will have mobile runtime – but not yet (as of Dec 2008)
Sun is positioning JavaFX at the mobile devices market, but no runtime have been released yet. Note that although JavaFX builds on the JVM and applet technology, it uses native DLLs to take advantage of underlying graphics chip. Conservative engineering means one has to be judicious in applying special animations and effects, especially on the mobile platform. I noticed that the JavaFX SDK ships with a JavaFX emulator (in the javafx/javafx-sdk1.0/emulator directory), I tried it, but didn’t have much luck with the pathanimation demo.
However, there is no doubt behinds Sun’s determination to see JavaFX succeed. Sun has pulled engineers from Swing and other projects to ship JavaFX 1.0.
JavaFX 1.0 is not ready for line of business applications on the desktop
Don’t get me wrong, JavaFX can be very productive environment to develop in, compared to Swing. Furthermore, JavaFX is (apparently) embeddable in a regular Swing application. However, the javafx.ext.swing package does not contain a DataGrid implementation, nor provides any guidance on how to handle virtual tablemodels. POJO classes will have to be rewritten to support property change notifications. For companies willing to experiment, there are several projects which implement custom classloaders to retrofit java classes with this ability. Sun should annoint one for use in their internal projects in order to improve code-quality.
JavaFX 1.0 is suitable for internal test deployments of media applets, games and simple proof-of-concept applications
We can’t get to JavaFX 2.0 without getting to JavaFX 1.0 first. While the platform is relatively immature, it is still useful for simple scenarios. In a corporate environment, where there is plenty of bandwidth and where standard operating environments is relatively easy to specify, JavaFX 1.0 can be useful for proof-of-concept applications.
Technical assessment of JavaFX Script
Java as a language is hobbled without a macro system, and as a consequence, JavaFX script has to be invented to
- remove the tedium when writing plain objects with propertyChange support,
- improved support for background animation threads and
- scenegraph layout code that reads more like layout than code.
It is somewhat surprising that Sun has not gone down the route of retrofitting Java with syntactic sugar, as Microsoft did with C# did using object initializers, but is introducing a brand new language instead.
Pragmatically, Sun has chosen not to standardize JavaFX script. This leaves the door open for more language tweaking. However, JavaFX script still lacks the dynamism of Javascript. Perhaps Douglas Crockford can show us how to flex JavaFX around as he did with Javascript.
JavaFX runtime vs HTML
I hold some strong opinions regarding this. Out of the three RIA platforms from Microsoft, Adobe and Sun, only Microsoft’s Silverlight retains the advantages found in web applications. These are
- Text selection
- Bookmarkability
- Text search
The JavaFX 1.0 runtime to date will not render rich text. JavaFX content is not indexable by web crawlers.
As such, JavaFX is not a substitute for text-heavy applications, like a bug tracker, or a blog – a web application’s equivalent of a “Hello World”.
There is no CSS support in JavaFX 1.0 [thanks El Cy], which is like programming without variables. One will have to touch sources at multiple points to effect a style-change.
The development experience is poor when compared to HTML. JavaFX is compiled rather than interpreted. As such, think of JavaFX as first Java, second Web, and has a lot of ground to catch up before it gains the same kind of ease-of-use compared to HTML.
From an adoption standpoint, Sun may gain mindshare of applet developers (from a very low or non-existent base), but will struggle to convince the millions of web-developers out there that Edit-Compile-Debug is more desirable than what they already have.
Conclusions
JavaFX 1.0 is not ready for prime time deployment. However, given Sun’s posturing, it is safe to conclude that Sun will continue to throw resources at the client-side. In order to ship JavaFX, a host of long neglected client-side bugs and issues have already been addressed. Watch Sun, and I can’t wait for JavaFX 1.1.
I’d appreciate any comments, corrections or questions.
8 Comments
Jump to comment form | comments rss [?] | trackback uri [?]