JavaFX 1.1 released, some first impressions
Main highlights, from the Release Notes and some findings:
- Official support for JavaFX Mobile. By "official", I guess Sun means v1.0-quality. It's not yet a real FCS because that will be when the runtime is shipping in real devices.
- A few JavaFX Script language improvements.
- Performance and stability improvements. No bug list in the release notes, so you must look this up in the JIRA. JavaFX 1.1 is the release codenamed Franca, its 148 fixed bugs (plus 7 unfixed) are here. A few dozen bugs are trivialities (documentation, broken tutorials), but it's still a good number of fixes for a ~2-month cycle since 1.0.1.
- Full-screen mode for JavaFX desktop. It seems this important feature was available for 1.0, but plagued by bad documentation and several bugs.
- The javafx.fxd package, previously an extension lib, was added to the core (common profile). In addition to the FXDLoader, you can also clone SceneGraph objects (with the Duplicator class) without deploying a library that may be larger than your applet; I'm still waiting for a more general clone feature though.
- Updated documentation (and that's still a weak spot of JavaFX). I noticed the updated javadocs, but the Language Reference doesn't seem to be updated at all (it's missing the new value types; perhaps just not uploaded yet?). There is a growing number of tutorials but I prefer good formal specs / references.
Evolution and Compatibility
The single language change seems to be in the typesystem: JavaFX Script now supports the full range of Java primitive types - with uppercase names like usual: Long etc., although the compiler avoids object wrappers whenever possible. Good news if you ask me - this makes JavaFX more Java-like, efficient, integrated with the mountains of Java code out there.
The non-incremental part of this change is that JavaFX's Number type was changed to mean float, instead of double. It's another good move; for FP, floats are much more popular in the domain of JavaFX (GUI & graphics): most toolkits, up to 3D APIs and including Java2D, use float precision for mundane things like screen coordinates - although you may need double for others, like transforms. In JavaFX one had to resort to the double-precision Number for large integers (e.g. millisecond timespans), which sucked for multiple reasons.
But this change means some code breaking. My JavaFX Balls code included; when I ran it on the new runtime, it sort-of-worked but the FPS counter was mad, reporting 2147483647 fps! (This is 0x7FFFFFFF.) I fixed the problem easily by changing a couple variable declarations from Number to Long.
Now, this issue is surprising for a development kit coming from Sun, past the 1.0 release, and with "Java" in its name: you'd expect perfect backwards compatibility (bugs aside) forever. But I'm happy that Sun is fixing whatever bad decisions they made aggressively, at least while they can - not much end-user JavaFX apps are already deployed. The runtimes can execute side-by-side (taking a page from .NET?), with both 1.0.1 and 1.1 deployed in the plugin's cache and each applete/JAWS app using the runtime it's built for, so the existing JavaFX applets out there won't break - but they won't automatically run on the new improved runtime either.
Performance looks roughly the same for the JavaFX Balls; the scalability issue with large number of balls persists. But that problem was not planned for a quick fix in v1.1, I expect this to be fixed or at least much improved in v1.5 (Marina) as the whole Scenario runtime is being beefed up - and additionally, JavaFX will get a full package of "native" (SceneGraph-based) components, plus V-sync animation and other important enhancements.
I didn't make an extensive test; JavaFX Balls is limited even as a JavaFX-centric benchmark, for one thing it doesn't even scratch the Effects framework. And now that JDK 6u14-ea-b01 unifies the 6u12+ features required by JavaFX 1.1 and the G1 collector, I'm going to do some tests because in theory G1 should rock for animation... I tested G1 before in early JDK 7 builds and it was slow and crashed, I reported this bug which is not yet fixed after ~3 months, so I don't expect the 6u14-ea-b01 version to be perfect yet. But I'll try it, and report here.
The development of mobile programs is indeed much enhanced. I have ported the JavaFX Balls to JavaFX Mobile (will soon release/describe this in next blog post), its performance was terrible and unstable in the beta emulator, now it's pretty good at ~73fps for 16 balls with 18% usage of a Q6600 CPU (so it's not using even a single of my 4 cores fully). Additional porting issue from the beta: I had to change VK_STAR to VK_ASTERISK; the former didn't map anymore to the "*" button in the emulator, even though the code still compiled.
Sun's site shows a list of partners backing JavaFX Mobile. Among handset makers, this only includes LG and SonyEricsson, I hope more will follow. My next cellphone (as always) will be one that comes with the latest and greatest Java installed, now including JavaFX Mobile. Other than that, I'm not of a gadget junkie, right now I have a Nokia 5610 which is a good MSA-subset device.
The bad news is that the mobile runtime is not yet available somewhere for installation on any existing devices. Perhaps this will happen next week, but I know it's a hard tab, most devices are pretty closed beasts. Danny says "You'll be able to get your hands on some of the JavaFX Mobile enabled handsets at JavaOne 2009, with consumer phones by the end of this year".