28 May 2007
With all this hype about JavaFX (!) since JavaOne (so much came out of that conference and has been by and large ignored because of JavaFX. This is most true with the prospect of 1-2 MB downloads for the JRE, the so called "Java Kernel"), I've decided to take inventory of the Java desktop landscape again, and see what's changed/grown since I've developed anything large with it. The desktop has languished behind the server in Java, often to the chagrin of the desktop / client-side developers who made the platform grow in the early, primordial java applet days.
First, I review the Rich Internet Application landscape in general, as it will serve as a useful backdrop against which all this new stuff makes sense.
And a heck of a lot more.
Things are different now. Microsoft recently announced (or, rather, formally debuted) their Silverlight offering, which is astonishingly good news in of itself. It presents the newly solidified Adobe/Macromedia gelatin with a diluting agent. It could also present the developer with a cross - platform .NET engine. The Mono project has already announced that it will support the plugin on Linux. The plug-in itself will run on OS X and Windows. Silverlight is a set of technologies, and is deployed using a subset of .NET technologies. Microsoft's new Expression tooling environments simplify development. It presents powerful opportunities for rich media applications, including streaming video, and animation.
Sun's Applets (naturally) predate any of these other items. They were the first to market, but unfortunately are the worst. Java Webstart is useful (very useful) where it's useful. Unfortunately, whereas you could see using Flash for an ad (for example), you could never use Java. First, it's too cumbersome to produce the same thing as in Flash using Java. Second, loading the applet itself has historically been wrought with issues: startup time, plug-in prevalence (and ease of adaptation), etc.
See how I did that? "Web 2.0"? "Java on the Desktop 2.0"? We need some sort of spiffy acronym here. "Java Desktop 2.0"! "JDeskto".. nah. "JD2". Nah. "JD 2.0"? Pronounced, "JD two point ohhh"? Maybe Sun should just corner the whole market and unveil something so hard to top that no one will even bother, like, "RIA 2.0". Who could argue with "Rich 2.0"? The "internet is the computer, 2.0". We could name it something to capitalize on the ridiculous amount of traction that Flash FX, and Flex, have achieved. Something trendy. Something with a "X" or two in it. It's got to be "Java". It's got to have that je ne sais quoi. And "X"-y. It's got to have an "X". None of this "E" business. That's gotten us in enough trouble. I have it: "Java FX"!
What about, "Java FXE 2.0"?
I worry the JavaFX name will suffer the same bloat that the Java and .NET names did. JavaFX is actually a set of technologies. It describes a scripting language (which doesn't necessarily need to be used for pretty looking user interfaces), elevated multimedia support, and a mobile platform. It will benefit from the Java Kernel (I guarantee you the Java Kernel wasn't developed so people could load .EARs quicker!) and from work being done in general startup time decreases. It also describes a runtime environment on mobile phones as well as the desktop. So when I say "JavaFX", I am more generally talking about everything Sun is doing to regain prominence in producing pretty user interfaces without HTML.
This is sickening because this was their market to lose, originally. Their applets were poised to be the platform that Flash became. They have been stalled by a general lack of attention from Sun on the desktop market, and a lack of attention to lowly web developers, in particular. There are many problems to solve which to some extent are already being addressed. Others are there if you know where to look.
For example, the common developer isn't looking to build a Microsoft Office, or a Photoshop, he's looking to build a forms intensive IS application. This is why Visual Basic had(s?) such a strong footing in corporate America: you could really quickly build some forms to babysit a database. That's also the reason so many people flocked to the web when it became apparent you could build forms to babysit the database. That's also why people are flocking to Ruby on Rails, because they get that most people just want to build forms to babysit databases, easily.
That's why it's called "Windows Forms", and not -say - "Windows UI". Naturally, the multimedia capabilities have arrived en masse for .NET, and Windows Presentation Foundation is a testament to its refined focus. However, at the end of the day, it's a super set, and not the normative application of Windows' UI facilities.
Have you tried building a basic Swing application to talk to a database in recent years? It's still unpleasant. Put another way, using Tapestry or Spring MVC, or even JSF to in turn use HTTP to fake stateful, event driven, interactive forms is easier than using Swing to produce stateful, event driven, interactive forms.
Don't get me wrong. It can be done. Through SwingLabs.org, JGoodies.com, L2FProd, and others, it can definitely be hobbled together. It's not for the faint of heart though, and it requires a body of knowledge most people don't have time for what is usually easily done via a standard web application.
There is hope over the horizon, though. Sun's made some positive strides with JSR 296 (the "Swing Application Framework": this ought to do you, but just in case you might also try this one). Thus far, the framework isn't final, but it is promising. Where JSR 296 falls short, other JSRs for data binding and persistence (for example) will fill the gaps. It addresses common infrastructure support, like a more worldly action framework, i18n support, and so on.
There are very few cohesive opportunities available right now, however. Oh, sure, you could ascend the mountain, your .zip of the Netbeans's or Eclipse RCP code in hand, and get somewhere, eventually. But that's hardly "approachable." Few people build applications as complex as your average IDE, it turns out.
A more substantive approach is Spring's Rich Client platform. The platform suffers from poor documentation, though that's mitigated more and more by the wiki. Using it, you're able to get the husk of an application up and running in literally minutes (assuming you've checked out the project and figured out how to get it working). Once you launch, it has 90% of what you're likely to need: dependency injection (it is Spring, after all), resource management (icons, labels, all internationalized and extracted to resource files), action framework, data binding, validation, a "view"/ "page" schema, and even integration with "sexy" technologies where it wouldn't be useful to develop it in-house. It also takes care of the corner cases, too. It'll automatically launch a splash screen for you, for example. The splash screen is automatically centered. It has integration with a few help systems.
I like Spring RCP (if that wasn't obvious). Within a weekend I was able to build an application that talked to a SOAP service using POJOs (that's Spring, of course) talking to my client application. The client application knew how to do all the CRUD things you'd expect. I was able to take advantage of some of the nicer tools and do things like integrate the application into the system tray so that it was only visible when necessary, integrate a video pane using JMF, and of course provide on-the-fly upgrades/installation using Webstart (that's mostly true…), all because it was Swing. The mind boggles at what you could do with JOGL, Java (2|3)D, JavaZoom, and most any application of a good look and feel! That took another weekend. Or two… I don't want to talk about it. My therapist insists it's good for me, though.
The bulk of the application - the part that justifies building the application - was mostly finished the first weekend, thanks entirely to Spring RCP. Now, granted, that second weekend was only possible because I've banged my head against those particular walls a few times before. Many times before.
The Java FX announcement is good news, as it means that all of desktop java will get some much needed attention. This is good news for java developers as it's one more place where they'll get the job and not some other programmer who's not using Ruby on top of a JVM. The pieces are all there. We have a really rich API for components /user interfaces. We have the rumblings of change in the framework space for Swing. Work's being done to evolve or supplant missing multimedia support. We have the language, the framework plumbing, the incredible depth of history with networked applications. All in all, Java's got a strong hand. Now we have a unified voice behind JavaFX. The hurdles at this point lay mostly in finding appropriate abstractions and spreading best practices. These hurdles are easily dealt with as a community, however. Java has nothing if not a community. All in all, I'd say it's a good time to be a Java developer.