Simon is a hands-on software architect and a senior consultant at 
JavaFX : why, how and when will it be successful?
Not until the mobile platform is released
At the August 2008 Coding the Architecture London User Group, I presented an overview of Flex, Silverlight and JavaFX. If you've watched the video from the session, you would have seen that I wasn't very complimentary about JavaFX.
There are a number of reasons why I don't think that JavaFX is anywhere near ready for people considering building RIAs at this point in time ... quite simply, the latest preview build ships with a bunch of crippled Swing components. Granted, some of this has been talked about in the recent SDN interview; but tables are gone, tabbed panels/tabs are gone, you can't configure how scrollpanes should scroll, etc, etc. In addition to the crippled Swing components, the out-of-the-box result looks ugly when compared to Flex and Silverlight. Take a look at the screenshots in the slides from my Flex, Silverlight and JavaFX presentation for an example.
I have some other complaints about JavaFX too, which I'll admit only stem from a couple of days with it. I personally found that the error messages reported by the NetBeans plugin are cryptic and I actually couldn't get some stuff to work because the error messages just didn't make any sense. Oh, and then there's that declarative syntax. MXML and XAML are far easier to work with. Although I appreciate the folding support that you get in the JavaFX plugin, it still took me a long time to figure out what was going on when a curly brace was missing. That syntax isn't productive and I don't see anybody (especially designers) using it without some decent drag-and-drop tooling.
In Does Anyone Really Care About Desktop Java?, Bruce Eckel talks about how Sun might be taking the wrong tack with JavaFX. And I agree. Java on the desktop is a tough proposition given the competition. So then, the important questions...
- Why are Sun doing this? : I don't know, I don't understand the impetus for doing this, aside from throwing the Java brand and an inferior Flex/Silverlight competitor into the RIA mix.
- How are Sun going to be successful with JavaFX? : I don't think they will be, at least on the desktop. I'd even go so far to say that they're barking up the wrong tree with the desktop platform. Flex and Silverlight provide a better development environment in which to build RIAs, plus the end results look *much* better than out-of-the-box Swing UIs. And then there's HTML 5. Sun should forget the desktop and concentrate on where the battle is really happening at the moment - the mobile platform. Think about it, this is where all of the action is happening right now. Think iPhone and Android. Flex and Silverlight are mature platforms in comparison to these, so why not take the opportunity and battle for supremacy in the mobile arena instead?
- When will Sun be successful? : Not until they release the JavaFX mobile platform, which (I understand) will be after the desktop platform has been released. I think Sun have got their priorities wrong ... forget about the desktop and make a stance on the mobile front before it's too late. Java ME has got massive support from hardware manufacturers. Why not do the same with JavaFX before Android gets a hold on the market?
I know it's (still) early days for JavaFX, but the preview version doesn't impress. Nobody may care about Java on the desktop, so why not focus on that mobile space instead.
Re: JavaFX : why, how and when will it be successful?
I'm a huge fan of Swing - it's one of the most flexible UI frameworks around but does show where one of Java's greatest strengths becomes one of its biggest weaknesses. The relentless pursuit of source and binary compatibility between Java versions has helped Java become a really solid platform for the enterprise but a bloated mess when trying to compete in a domain as reactive as the desktop. Swing is poorly documented and inconsistently implemented; without access to the source code it's a washout. Additions like Synth are good ideas but so blinkered in their implementation that they feel more like an incubator project than a fully-fledged addition to the core APIs!
My £0.02 (or whatever the chancellor's devalued it to today) on JavaFX is that Sun have made a big mistake by effectively excluding their biggest asset: a huge developer base. The syntax is uncomfortable to Java devs and you can chuck away your mature tools. Are they really hoping to attract the Adobe or Microsoft community across to Java? Heck, they can't even keep their own Swing team interested in it! Perhaps they're after the web dev crowd - but ended up with some JSON/Java mutant instead of a decent ECMA Script derivative like Flex's?
I agree with you that the desktop is the wrong place to start. It makes JavaFX feel like some crappy Swing wrapper. When looking at it in that way you're left asking why Sun didn't just give us a decent bean-binding syntax and timelines to make Swing development easier.
As for the (much-discussed) pending rewrite of a scene-graph variant of JTable I wonder how important its omission is. I couldn't conceive of writing any of the data-intensive Swing apps I've worked on in JavaFX! A scene graph variant might not scale to the same volumes of data as JTable if JavaFX's resource woes are to believed. What other benefits does JTable really give you that a suitable layout manager wouldn't? I'd be much more interested to hear in some new components: graphing and charting in particular!
Re: JavaFX : why, how and when will it be successful?
Re: JavaFX : why, how and when will it be successful?
Re: JavaFX : why, how and when will it be successful?
Most developers know very little about design (or care about design), with the top 10 percentile remotely capable of mimicking existing designs.
Existing tools to lay out swing components is adequate. Not much bling, but it is functional.Wherefore, JavaFX?
Re: JavaFX : why, how and when will it be successful?
Re: JVM, bytecode verification
In Sun's case, the JVM itself it the issue, and JavaFX or not, it will find it hard to dig itself out of this hole.
When Flash 1.0 came out, it supported streaming bytecodes, and movies played immediately. JVM's design requires all libraries to be downloaded, and then verified before playing in the sandbox.
The JVM implements share-nothing class libraries, every new JVM process requires run-time libraries to be loaded up separately. This adds another block of run-up time before any screen is visible.
The JVM has a fundamentally flawed approach when the use-case is to run in a browsed environment, i.e. where people are moving from web page to web page quickly, and only having a taste of your application, and sometimes, involuntarily, as in the case of a banner ad.
For browsing environments, I contend that Sun should have bundled some sort of interpreter in the VM, that can process a streamable language, in the manner of Flash. Sure, it is not Java, but it would have guided the evolution of the JVM. For example, we would have arrived at MultiVMs and OSGI much faster.
The Java camp has a reputation for dogma, e.g. rejecting delegates in favour of anonymous inner classes, static methods instead of standalone functions. If the JVM had evolved to the point of accepting first class functions and dynamic dispatch, then Java itself would grow into a more vibrant language.
