Sun's JavaFX must toolup against Adobe - pronto
Ask not for whom the school bell tolls...
JavaFX, part 2 Sun Microsystems lost the first Rich Internet Application (RIA) war when Macromedia (now part of Adobe) ate its applets for lunch following a schoolyard brawl. Now Sun has a second chance.
But, to succeed in such an unforgiving market, Sun needs something special. A mature, powerful platform, a buzzing community, some seriously talented people with an eye for visual design, and some butt-kicking WYSIWYG tools so that non-programmers are invited to the party as well.
JavaFX ticks some of these boxes, and it has tools on the way. These tools, though, are going to make or break its chances. And they're a little late, to be honest. Spring 2008 was mentioned for the visual development environment. Spring has given way to glorious summer.
Currently there's a limited NetBeans plug-in that provides some text editing and compiler support, but that's as far as it goes. There is no tree-based navigator view of a file, there's no properties view of the current node - you just have to either guess or know what properties are available or valid. And, above all, there is (as yet) no WYSIWYG graphical user interface editing. These are all things you currently get for Swing development.
If Sun's goal is to compete with Adobe's Flash or Silverlight from Microsoft, then a Matisse-based visual editor should have been one of the first toys to be pulled out of the box. It should be right at the center of the rich client development experience rather than a "potential add-on some time", leaving third-party vendors to pick up the slack.
Hard lessons of EJB
My main concern with JavaFX, though, is that there is no clearly targeted audience. Web designers? Java-literate programmers? What problem is Sun attempting to solve here? JavaFX is very programmer-centric, but not even as "friendly" as Swing.
Even those involved in its development don't appear to be sure. In this interview, senior engineer in Sun's Java client group Amy Fowler is asked about the target audience for JavaFX. Her reply suggests that there just isn't a clear answer at the moment. She divides JavaFX into two conceptual areas and talks about each area separately. This harkens back to the artificial separation of roles in the original Enterprise Java Bean (EJB) spec.
Given the success of Adobe's Flex, the mission statement for JavaFX should simply be: make JavaFX 1.0 just like Flex.
Or, if this ruffles feathers, something just as clear-cut: provide a simple, fast way for non-experts to write rich-client multimedia applications.
Then, anything which doesn't clearly fit into this should be struck out of the spec. And if any part of Flex runs rings around JavaFX, then make that area a top priority.
Every demo, every default, should look gorgeous: meaning, it should provide things like a nice subtle gradient for blank panels instead of the default dead-flesh grey background.
You'd want someone's first experience with a "Hello World!" application to blow their socks off visually, not make them recoil. The JavaFX engine should be doing its utmost to show off its visual power every chance it gets; it shouldn't rely on the equivalent of Swing hacks or rockstar coding to get it looking good.
In Sun's defence, this is nothing new. Sun's babies have always been ugly. The startling purpleness of Swing's look and feel (up until quite recently), combined with the ugliness of early versions of NetBeans, the horrors of Abstract Widget Toolkit (AWT), and so on, proved on many occasions that Sun's people are very much programmers, not designers, not rich UI people.
Despite these pretty major problems, there is much to like about JavaFX, even in these early stages. For one thing, it's built on the highly mature Java technology stack, giving you powerful networking, multithreading and of course full access to the excellent Java2D.
However, Sun is taking its usual slow time to get it right, instead of charging out of the gate with a visually polished experience that bowls over web developers. Some of this criticism may seem unfair or premature, as the product isn't officially released yet. However, while Sun dawdles along spending years getting it right, it looks as if Macromedia - this time with Adobe - is going to eat Sun's lunch all over again.®
Matt Stephens is co-author of Use Case Driven Object Modeling with UML: Theory and Practice, which illustrates how to get from use cases to source code and tests, using Spring Framework, JUnit and Enterprise Architect.