JDK 6u21, JavaFX 1.3.1 and Deployment
Now that JDK 6u21, JavaFX 1.3.1 and NetBeans 6.9.1 are all finally released, I'm back to checking the latest news and improvements in JavaFX. The official Release Notes points to the deployment improvements as the single new end-user feature, so I've checked the latest improvements in this area.
The really major feature of this release is for developers: debugging and profiling will now, well, work as expected. With my excuses to the javafxc team that worked a lot to make this happen, it's just not exciting, headline-worthy material... still I have some comments about the compiler update in the end.
It's the Deployment, Stupid!
JavaFX's feature set is decent at least since 1.3, although more is needed / is coming (TableView, etc.). But even by 1.2, deployment was already perceived as the biggest problem - for any Client Java, including Swing and runners-ups like Apache Pivot. A recent blog from Max Katz summarizes this well, section The Ugly stuff. Java's deployment has been ugly for so long that it takes some faith to believe it can be fixed.
Faith has been rewarded, though, even if not with miraculous speed. The JDK team continues the "6uN" project, delivering incremental client-side improvements in a roughly half-yearly pace. The latest such release is 6u21, which brings these significant enhancements:
- Java HotSpot v17: Not client-specific, but extra VM performance never hurts! More fresh goodies backported from the JDK 7 project, including memory management improvements (better CMS and G1 GCs, Escape Analysis, 64-bit CompressedOops, code cache changes to reduce the risk of PermGen blowups).
- Support for Custom Loading Progress Indicators: Used to great effect by JavaFX 1.3.1.
- The usual batch of bugfixes: Java2D, AWT, Swing, plugin2 and other components. Remarkably for Java2D, a fair number of font-related fixes, including rendering quality enhancements and optimizations.
For JavaFX, 1.3.1 is a maintenance release, but it boasts one significant new feature, the new Application Startup Experience including a cool new progress indicator and more fine touches. Let's check Max's comments:
- Browser freezing for cold-startup of Applets: Problem persists... why? How difficult is to initialize a plugin in the background, not holding any browser thread / lock / whatever until fully initialized? There are excuses for the JVM's loading time and resource usage (big, 15-year-old platform...); but the Browser Freeze From Hell is hard to accept, remarkably after the plugin's 6u10 full rewrite.
- The dreadful animated Java logo, that didn't report real loading progress: Gone! Point scored.
- Scary security dialog: That's slowly improving. The main thing is avoid nagging for apps that shouldn't have security concerns. JDK 6u21 fixes one bug involving drag&drop and security. Other recent JDK builds have tweaked more details (but, too bad that 6u18's removal of mandatory codebase didn't work, reverted in 6u20 - temporarily?). You can go very far with the current FX platform without signing or permissions; and when you need that, a "scary" one-time dialog is the right thing to do. A RIA runtime should not be a big backdoor. Notice that unneeded security warnings are sometimes due to poor application programming / packaging.
- Error reporting: This is still an issue. The Java Console is great for developers, but a fiasco for end-users. It should be disabled by default, and a new, user-friendly mechanism is needed to report any failures. That must be native code, so it works even if something like JAWS fails.
Some extra items that come to my mind:
- Installation: Also slowly improving. JavaFX 1.3 modularized its core runtime so most apps won't need to fetch all of it from the web (or even from the plugin cache) if they don't use certain feature (like the javafx.fxd and javafx.scene.chart packages). JavaFX 1.3.1 further hides the annoyance of first-time FX execution behind the progress indicator.
- EULA: Argh, 1.3.1 still shows an atrocious EULA dialog when you run the very-first FX app. But that's probably hopeless.
- Redundant Plugin: Anybody noticed that all modern browsers have an OOPP (out-of-process plugin) architecture? Java 6u10 created its own out-of-process layer (jpl2launcher), but this is not required for the latest browsers. When I run a Java applet in (say) Firefox 3.6.4+, I get this Java plugin process and also Firefox's own plugin-container process. That's stupid, one extra process (and I guess one extra level of IPC indirection, security barriers...), to achieve nothing. The plugin should detect these new browsers and then just run "in-place" (that is, isolated in the plugin container process).
- Plugin/Browser Artifacts: I only see refresh and scrolling artifacts, for Java Applets, on Firefox 4, and only with the new Windows rendering acceleration (Direct2D / DirectWrite / Layers) turned on. FF4 is still beta, with many known bugs on the new accelerated pipeline, so that's hopefully just a transient browser issue.
- JNLP files: WebStart's launch experience is polluted by these files, that are dumped into some temp directory and appear as regular downloads in your browser's download manager or statusbar. If you're unlucky enough, you'll even get a download/run confirmation dialog. The reliance on .jnlp's MIME type is fragile, both in the browser and in the server. The extra HTTP request may be noticeable for small applets over slow connections. The plugin and JAWS should create some alternative mechanism. Like an <object> tag containing all JNLP metadata - hey, that works for both the old-and-busted Flash and the new-and-cool Silverlight, so I assume that <object> is just great: so, anybody care to explain why was the external JNLP file invented in the first place?
In my account, that's 2 items fixed (2, 8) and 2 items improved (3, 5) out of 9 issues. That's not bad, but Oracle definitely needs to keep working hard and fast, remarkably on item 1 that is very often the single big offender in "Java-powered" webpages.
The Undocumented Bits
- Updated, complete, high-quality JavaFX Script Language Reference and formal spec;
Javadocs for the Preview controlsThis is here, missed it somehow!!
- Any official information about the Prism toolkit;
- Any official "internal" information, e.g. for the various system properties that can be used for tuning and diagnostics.
I understand that all these items are in the "under construction" category - even the JavaFX Script language is still a moving target, although not as fast-moving as in the past. But some docs help a lot the early adopters, enthusiasts and
Testing the New Deployment
I exercised 1.3.1 by updating all the JavaFX applets and JAWS apps in my blogs: JavaFX Balls, StrangeAttractor and Game of Life. I performed some startup tests - warm, cold, and "freezing-cold" (cleaning my plugin cache to force reload of the JavaFX runtime). The combination of the latest Java and JavaFX runtimes, and the updated JNLP files to request the new progress indicator, have definitely improved all scenarios of startup. So, this feature worked as advertised, pretty good! Definitely not yet in the Flash league of startup experience and speed, but definitely another significant step forward.
Now, what about real-world, complex JavaFX apps? The samples are updated, but these are smallish. So I went back to the Vancouver Olympics applet, the big showcase of JavaFX 1.2. Unfortunately it's not updated; not even to 1.3.0, it loaded the crappy old JavaFX 1.2.3 runtime with the now-ancient-and-crude startup experience. Yeah I know that these Winter Games are long over, but their site was apparently a partner of Oracle to promote JavaFX, so I'd expect them to keep it updated to the latest JavaFX release. On the plus side, Sten Anderson's great Music Explorer FX was updated; try it. Maybe Oracle's marketing dept is just pouring cash in the wrong pockets! ;-)
Testing the New Compiler
I've also rebuilt all jars, but that's just for my second test: Checking if the updated javafxc compiler had any improvement or regression. As I blogged before, javafxc 1.3 was a step forward in performance (remarkably the compiled-bind optimization), but a step backward in code size; but many further optimizations are planned, including several ones to reduce current space/speed tradeoffs. 1.3.1's major theme for javafxc is the JDI support; its list of fixed bugs doesn't seem to contain any code generation improvements (the next batch seems to be planned for 1.3.2). But... who knows? Also, I was worried if the big debugging work could mean a regression in compiled code size: maybe the new compiler would generate additional debug information, annotations or helper code.
So, I've repeated my simple Static Footprint benchmark. The numbers for 1.3.0 are slightly different due to a few small updates in my programs. I've also added a pack.gz metric that shows the smallest possible deployment size, just for the classes + META-INF data (removing any resources, such as images, from the source jar). Finally, the stripped metric is for a .pack.gz that's additionally stripped of any debug info (with the --strip-debug option; the pack200 tool won't do that by default!).
|Program||JavaFX 1.3.0||JavaFX 1.3.1|
|HelloWorld||2 classes, 2.579 bytes
pack.gz: 954 bytes
stripped: 782 bytes
|2 classes, 2.731 bytes (+5,8%)
pack.gz: 1.024 bytes (+7,3%)
stripped: 876 bytes (+12,0%)
|JavaFX Balls||20 classes, 118.559 bytes
pack.gz: 18.787 bytes
stripped: 13.828 bytes
|20 classes, 116.539 bytes (-1,5%)
pack.gz: 17.935 bytes (-4,5%)
stripped: 13.852 bytes (+0,1%)
|Strange Attractor||57 classes, 393.332 bytes
pack.gz: 21.119 bytes
stripped: 13.040 bytes
|57 classes, 378.641 bytes (-3,7%)
pack.gz: 20.038 bytes (-5,1%)
stripped: 13.167 bytes (-0,1%)
|Interesting Photos||46 classes, 457.561 bytes
pack.gz: 49.587 bytes
stripped: 37.842 bytes
|46 classes, 438.619 bytes (-4,1%)
pack.gz: 46.073 bytes (-7,1%)
stripped: 37.845 bytes (0%)
|GUIMark||27 classes, 224.904 bytes
pack.gz: 17.224 bytes
stripped: 12.955 bytes
|31 classes, 217.390 bytes (-3,3%)
pack.gz: 16.552 bytes (-4,0%)
stripped: 12.989 bytes (-0,2%)
The first results look surprising: all programs (except the unrealistically-small HelloWorld) show improved code size, up to 4,1% smaller without pack200 compression, and up to 7,1% smaller with Pack200. These would be excellent numbers for a maintenance update that's not supposed to contain any code-size optimization! But checking the stripped numbers shows virtually identical sizes. The conclusion is that all differences are very likely just side effect of the debugging support changes. The updated javafxc is smarter, producing debug info that's both smaller and better.
Of course, for stripped bytecode there is no advantage at all. But the advantage of non-stripped files is still important, because Java developers very rarely strip debug info. (The NetBeans project settings page doesn't even offer an easy checkbox for pack200's --strip-debug option; I'd bet that many Java developers don't even know that such option exist.) Besides that, the fact that the maintenance for debugging support didn't cause any regression in code size, is another good news.
The new SDK contains a new /runtime directory with the redistributable Desktop runtime. But it's not clear if we actually have the right to redistribute these files, and under which conditions - I didn't find a redistribution license. This option is very important for some people; we need some enlightenment about this.
The absence of a redistributable JavaFX Mobile package is quite remarkable. The mobile runtime was updated in both 1.3 and 1.3.1 cycles, it just wasn't released to the public, so the only version of JavaFX Mobile that you can actually install in a real handset is the now-Jurassic v1.2. JavaFX's mobile plans are stuck for non-technical reasons, as Oracle probably works on its strategy; the M.I.A. JavaStore may also be part of the same imbroglio. The JavaFX TV runtime is not available either, although its status doesn't seem so bleak (it's not late to the race; it didn't have a faux pre-launch like JavaFX Mobile and Java Store; and it depends on Prism and other components so its non-shipping status may be just for the reason of not being ready).
Well, that was the speculation we already did by 1.3's launch. Now with Oracle's moves against Android, we may just be watching the beginning of the next chapter. I have already posted some thoughts on a specific, technical part of this debate; but I'm holding my breath for the final consequences for everybody - Java and Android developers. In my dreams, my next smartphone would be a 'droid that could also run JavaFX programs... let's see how all this works out. Hopefully we only have to wait another month, as Larry Ellison and Thomas Kurian will spill the beans about Java Strategy and Directions. We need directions indeed, they can't come soon enough.