Skip to main content

JDK 6u21, JavaFX 1.3.1 and Deployment

Posted by opinali on August 21, 2010 at 3:07 PM PDT

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:

  1. 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.
  2. The dreadful animated Java logo, that didn't report real loading progress: Gone! Point scored.
  3. 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.
  4. 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:

  1. 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.
  2. EULA: Argh, 1.3.1 still shows an atrocious EULA dialog when you run the very-first FX app. But that's probably hopeless.
  3. 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).
  4. 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.
  5. 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

JavaFX 1.3.1 published some important new documentation: the complete CSS Reference Guide, and a good FXD Specification. Keep 'em coming!  We're still missing some important docs:

  • Updated, complete, high-quality JavaFX Script Language Reference and formal spec;
  • Javadocs for the Preview controls This 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 betapreview testers.

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.

Missing Deployments

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.



It sounds like a lot of headway is being made but I find it really hard to get excited about JavaFX. It doesn't have the penetration, performance or tooling that flash/silverlight has for the 'consumer' web and w/o a robust table widget it's basically worthless to an enterprise. A java dev can't even leverage their existing skill set since it's a whole new language w/new concepts and paradigms. I'm having trouble understanding what JavaFX's niche is.

It could be a viable technology at some point but, despite the version numbers, this is pretty clearly still a beta product. What worries me is microsoft/adobe aren't sitting still, HTML 5 seems to be offering a lot of the technologies needed for RIA and the browsers are advancing at a scary pace on almost every 'killer' feature (threads, direct pixel access, hardware access, etc). I don't see JavaFX touching android or iOS products on mobile and adobe/html 5 are still major competitors in the mobile space as well. How can JavaFX possibly differentiate itself when it's so far behind the game to begin with?

"Beta" is perhaps too harsh...

...and I have myself qualified previous JavaFX releases as "beta" in quality or completeness, check my older blogs. But v1.3.1 is certainly, safely beyond that level. Some important features are missing, but this will always be true - as you put, it's a matter of finding the niche that JavaFX already serves well. There are tons of interesting Flash apps out there that don't use any Table component, so it's fair to state that JavaFX would be useful for the same apps. You can also look for alternatives like JFXtras as a stopgap solution for controls that are still planned for future JavaFX releases.

It's certainly not true that JavaFX "doesn't have the performance of Flash or Silverlight". Some aspects of JavaFX's performance ar on a par, or even much superior than its competition. For one thing, the HotSpot VM (even the Client variant) runs neck-to-neck with Microsoft's CLR inside Silverlight, and it wipes the floor with Adobe's AS3 VM (not to mention JavaScript VM, even from bleeding-edge browsers). Many RIA apps don't need much code execution performance as they spend most of the time in their runtimes (media codecs, controls, networking etc.), but some others do. JavaFX has some performance disadvantages but these are mostly the deployment issues that I discuss here - remarkably startup time. If Oracle can make some extra improvements here, I will certainly count JavaFX as highly competitive with alternatives like Flex/AIR and Silverlight. (Maybe just not with "pure" Flash or HTML5; these will always rule for simple things like ad banners and video players.)

I don't agree either that "a Java developer can't leverage existing skill set". I am a Java developer, not even a Java GUI developer. I was an early adopter of Swing and built some reasonably complex apps with it; but that was ten years ago and I basically haven't touched AWT/Java2D/Swing since that time - can't write a Swing HelloWorld app today without looking up some docs or relying on significant IDE assistance. And I picked up JavaFX very easily. If different languages and libraries were such a problem, people wouldn't be defecting to even more different alternatives like Flex, Silverlight or iOS. Of course there's a difference between learning a new toolkit, and mastering a new toolkit. But once again, that will be a relatively slow process for any competing RIA platform (including HTML5, which is a quite big and complex platform, not to mention a freaking mess - most people won't build realistic complex web-apps without several layers of shielding, all way from JQuery to GWT.).

On the mobile availability of JavaFX, that's fair, as I mention in the blog that's right now in a limbo... I expect some important announcement at next JavaOne, and some very good release and device deployments for JavaFX Mobile by v1.4, otherwise we can probably forget about mobile and focus on desktop and maybe TV. On the other hand, even this expectation may be in part anxiety. Most people thought that Apple wouldn't have a chance when they entered the then-entrenched, competitive smartphone market. Or when Microsoft entered the game console market. It's surprising how many market assumptions can be broken by a very good product and strategy - and if Oracle believes in JavaFX, they (different from Sun) certainly have the resources to fight a long battle if necessary. But anything, either pessimistic or optimistic, is speculation at this point; let's wait and see.

yea !

I do agree that java's JVM Horrible startup (time and gui) was such a killer for all Sun/Oracle hopes on the "rich media" side. I just tested my aplets / application with the new -u21---> I find Better performance, a bit less time to start. And best of all ... No warning messages. (so good ! ) Finally java could prepare a successfull return on the "Web page ruch media" side. I just hope so... but boy how long it took to have those....