Ten Questions for Java FX
Kudos to all the Sun hackers involved in this project. You overcame a large amount of negative expectations, perhaps because Sun announced FX too early or because Java SE was in discredit as a RIA platform (6u10 was already a major step to fix that). But I was pleasantly impressed with the FCS. Java FX has great potential, and it could make a really big difference in both the desktop "RIA wars" and in the new, ultra-hot mobile market.
But I'm approaching FX with a degree of caution and critical spirit. So, I compiled a small list of very important questions that I hope Sun (or others that have been tracking FX better than I) can answer. I think at least some of these questions are critical to the long-term success of the new platform.
1) When will Sun publish a complete specification? I found the API javadocs and Java FX Script language reference. But I want full, formal specs of things like new file formats (like FXM and JXD), the FX Mobile Stack, and anything else that's "under the hood".
2) Any plans for an open source release? The SDK comes with very limited source code (tiny part of the javafx.* packages). It seems the FX Script compiler and the Scene Graph package are already covered by open source projects, but I don't see their sources bundled with the 1.0 SDK, and the full FX platform is clearly much bigger than those two components. (There are some pieces that Sun licensed from others, like the On2 codecs - no problem not having those sources, as long as item (1) is fulfilled.)
3) A detailed roadmap? It would be important for any stakeholders to have a clear vision of the next milestones. It seems the next releases will come fast - I like that, but should I understand that the just released v1.0 is just a "developer release" because you're still working furiously on the implementation and the real consumer-oriented kickoff will be v1.1 (Feb'09), 1.5 (Jun'09) or 2.0 (late '09)? And how about a visual designer for NetBeans, that is sorely needed?
4) Where is the public bugtrack? I'm way too used to the level of openness of the current Java platforms (SE/ME/EE) with the Bug Database, JCP specs etc. At this point FX is a Sun product, not a JCP standard (hopefully this may change in the future as Jonathan Schwartz hinted). But even for a commercial platform, and even if you don't plan to release full sources soon, a public bugtrack would make a huge difference. (P.S.: Don't make a large step backwards, now that you advanced so much with the open-sourcing of virtually all your software portfolio and people just stopped whining about the "Java Trap".)
5) Do you have plans to reduce the desktop FX runtime's dependency on Swing? I ran a HelloWorld-class test (SDK Clock demo) and it loaded 2,300 classes, including an unholy number of Swing classes (the entire Nimbus LAF, all sorts of components like JButton, JMenuItem etc.). Swing is a nightmare of tight-coupled bloat, so perhaps FX is using just a couple fundamental classes but these are bringing together the other ~200 classes that I see in -verbose:gc. That's probably part of the reason why this tiny demo takes a full second to load (warm!) in my laptop. Not bad, but still perceivably worse than a Flash app of similar size/complexity.
6) Can you share more details about the FX Mobile platform? In the past it was planned for the CDC, now we know that CLDC/MIDP (with full MSA stack) will be supported (I guess CDC will also be supported). What about the full stack story including a fresh new OS with Linux kernel, some Savaje technology etc.? Do you plan to offer several deployment options, e.g. a complete Java-centric mobile OS for the boldest device makers, and a "thin layer over CLDC/CDC" for others that decide to keep their Symbian or other OS? Any words specifically on Windows Mobile and Blackberry support?
7) What's the reason to create a new vector graphics format, the FXD? I looked at this format, and it seems to be a SVG clone with disadvantages: it's different/proprietary, and the files are a bit bigger (for a few SVGs I converted, anyway). Packing FXD with ZIP compression (FXZ) makes not an efficient format. The current Java ME platform adopts standard SVG (Lite). Now, if the answer is that FXD is more powerful (can do things SVG cannot), parses faster etc, why not having an efficient binary format? I don't buy the tradeoff of bloated ASCII, human-readable formats for graphics files that may be very large and have to load very fast, even in small devices. If you're making the option to have a new file format with all inconvenience this brings to developers and content creators, you could have used the chance to design a high-perf format... even SVG (or a FX-centric XML) over FastInfoset could be very competitive in size and parsing speed, without losing the flexibility of XML.
8) Some people complained about ugly security dialogs. A few demos require this because they're using protected features, e.g the ScreenshotMaker app captures the whole desktop screen, so a malware could take a photo of your online banking screen... you must educate people of this need, in LARGE FRIENDLY LETTERS in the demos' pages. Otherwise, the blogosphere becomes full of FUD like "Oh how ugly is Java FX user experience, Flash doesn't show that security crap". But there are other cases, e.g. I don't see why the VideoPuzzle demo should bother me with a certificate. If that's bad demo code, fix/kill the demo. And there are other "smooth experience" issues you should take seriously: Drop the Java logo from the loading animation. Make the plugin's System Tray icon disabled by default (only developers need that turd). Fix the Plugin and/or JAWS so browsers don't download the JNLP files as normal files in a temp directory, then show that file in the browser's download window/manager/toolbar, and just then launch the JAWS app - for god's sake, just start the app without exposing any stupid JNLP file to the user. (If it's the browsers' fault, just refactor the JNLP loading into the JPI launcher.) Make the JRE and JavaFX as "invisible" as Flash. (Otherwise, Java Applets may continue to be really invisible just because web developers won't use them.)
9) When will the JRE CDS be enhanced to support non-RT libraries? Another reason for Java FX's boot time being less than ideal is that its multi-megabyte runtime does not benefit from Class Data Sharing. And this increases memory usage too. If you don't have a plan to allow libs/apps benefit from CDS (like the IBM JDK does), perhaps we could at least make a special case for Java FX.
10) Perspectives on performance? I noticed a less than perfectly-smooth animation in a few complex demos. For example, SmokeParticles exhibits this behavior because it runs full-GC very often. Then I profiled it with NetBeans, and I see that it allocates a massive volume of AffineTransform and Rectangle2D.Float objects. These allocations happen very deep in the SceneGraph runtime. The nested sequence of recursive getBounds() invocations that I see in the call stack, is an obvious candidate for "fast path" optimization - i.e., implement optimizations like preallocating and reuse objects, even at the cost of screwing with the architecture, in that critical activity. Perhaps you can cache such objects per instance of SGNode. Anyway, the good news is that the JX Script code is in such a high level that you can mess a lot with the runtime, for performance or other reasons, without compatibility issues. The bad news is that you MUST do this continuous optimization effort, because the FX Script code is on such a high level, that the FX programmer has little chance of hand-tuning that stuff. Now that 1.0-FCS is out and people start to build really big, complex apps, expect more demands like this. ;-) P.S.: Even at the current stage, FX beats the pants off any competitor. Try writing a demo like SmokeParticles in other RIA platforms...