Delusion-Free Desktop Java
by Chris Adamson
Ted Neward's 2006 Tech Predictions are a fun read, starting off with predicting the fading of AJAX hype, and later predicting the almost inevitable letdown as Ruby's balloon deflates. They're still good technologies of course, but right now, they're both at that "Java in 1997" stage, which means they're pissing a lot of people off, especially Java developers.
Along with some other nuggets for the Java community about EJB 3.0 and the path to Dolphin (Java SE 7), Neward drops this little nugget.
Java developers will start gaining interest in building rich Java apps again. (Freely admit, this is a long shot, but the work being done by the Swing researchers at Sun, not least of which is Romain Guy, will by the middle of 2006 probably be ready for prime-time consumption, and there's some seriously interesting sh*t in there.)
Problem is, the periodic prognostications of Desktop Java's resurgence remind me too much of the oft-predicted rise of the Linux Desktop. Both are based on a mix of sound reasoning and wishful thinking, and when they consistently fail to come true, it reminds us that there's still too much of the latter and not enough of the former.
The reasons for Desktop Java's potential success are still there: even with AJAX, the web experience can only take you so far. With media apps becoming increasingly significant, something that browsers aren't well suited for, Java has yet another opportunity (pity, then, that the official Java media API's suck so bad). The story of a single executable providing a rich client across platforms is still compelling, particularly to those on platforms that get left out in the usual "available now for Windows, Mac later maybe, and Lin-what?" announcements.
But those reasons have always been true, and somehow, they've apparently never been compelling enough. Well, not in the public realm. All the Desktop Java developers I know work in the enterprise, generally distributing their work only within a single company. This makes it really hard to get a sense of just how big or small the Desktop Java community is. It was certainly surprising, for example, that Swing Hacks was the #2 seller at the JavaOne bookstore last summer. Nobody, authors included, really thought there were still that many people in the Desktop Java realm.
In other words, take away GMail and Google Maps, and 1/3 of the discussion about AJAX goes away.
A modest proposal
So, imagine this: what if Google started writing Java apps? Imagine if they started with Google Earth, the drool-worthy 3D map interface that all the Mac and Linux zealots have been begging for? What if they started doing some of their other rich clients in Java? As Google has become a (the?) standard-bearer for internet applications, able to legitimize a technology like AJAX by adopting it, this would be huge for Java.
Why, it's enough to make Sun get together with Google. Except that, um, wait, they already did. And announced that... dramatic pause... Sun would be distributing the Google Toolbar as an optional include with the JRE download.
Pause for the unique combination of incredulous laughter and heartbreak.
I don't know what Sun could offer Google to get them to sling some Java magic -- Google probably already has enough money and Sun probably doesn't have much left -- but just as a technical challenge, it seems like something that would be up the Google engineers' alley.
Setting aside what, ultimately, may simply be a pipe-dream of Google as a white knight, riding to Desktop Java's rescue, there are a couple things I think the Desktop Java advocates could for themselves do to help their cause.
First and foremost: end the insane "pixel accuracy" arms race. Java apps don't have to look exactly like native apps to succeed. None of these wonderful web apps are particularly Windows-like or Mac-like, and they're quite successful.
The "doesn't look native enough" line is about as useful a critique as the famous "too many notes" line in Amadeus. It's an insincere slap from people who typically either a) would never accept Java for political reasons, or b) don't know what they're talking about. (b) is usually your boss -- I've worked for him too -- who doesn't see the value of your software (or, in some cases, accurately realizes your software doesn't have any value) but perceives only the surface gloss and not the underlying functionality. There's a solution for this: sometimes, for the sake of yourself, your company, and your profession, you really need to tell the boss to shut the f**k up.
Pixel-accuracy has led to a miserable fool's errand for both of the major Java GUI toolkits, Swing and SWT. Being rather coupled to the native Windows API's, SWT should enjoy a huge advantage here, but its obsessive fidelity to Windows' GUI shows no signs of ushering in a new era of Java Desktop development... just a lot of very loud evangelists, and complaints about its performance on other platforms. Swing, despite its bulk and sometimes ruefully ornate design, is probably better suited for the long run, because its goals are ultimately based in functionality, not appearance.
The missing pieces
I think there are two desperately needed pieces to the Java Desktop puzzle. We can muddle by without them, but fixing them would get some fresh eyes on this space.
- GUI builders done right And by "right", I mean "like the Mac's Interface Builder". And by that, I mean they persist freeze dried objects and not code, and they foster a specific, best-practices way to develop an app. On point one, anyone who's written a thousand lines of
GridBagLayoutwill see that generating this code is simply moving the problem -- it's a completely different world when you build the interface first, and the first meaningful moment of your components' life is not the execution of the constructor and layout code, but a
wakeFromNib-type message. I've never had anyone give me a good technical reason why this can't be done with Java, and why we have to resort to generating code instead. On point two, you have to use XCode and Interface Builder to get it, but it's kind of hard on the Mac not to define and instantiate proper controller objects as brokers between the UI and the model behind it. Swing turns MVC into a compromise called "model-delegate", and in retrospect, that was probably a bad idea.
- Deployment done right At the end of the day, we're seriously supposed to launch our apps from a command line, or an obfuscated equivalent thereof? 10 years after Java launched, JAR versioning is still a fiasco, finding the right version of a library utterly miserable (ever had fun with
ResourceBundles are little understood and less used, bundling your images, sounds, etc. is a roll-your-own experience, and you're probably going to get to do it all differently for each platform. Which probably means you'll do it for Windows and go home. Mac envy applies again: the OS X bundle is a beautiful thing, and Java would do well to support something like it, at the VM level so developers could count on it, on every platform.
Will fixing these magically usher in a new age of Java Desktop development. No, I doubt they're a big enough deal unto themselves for that. But they're so obviously broken now, that they should be the top candidates for new focus and serious development. The first and maybe the second could probably be done with or without Sun's involvement, by an open source project (or competing projects), given the right mix of inspiration, vision, and effort.
Or maybe this is just more wishful thinking.
Or maybe a bunch of nifty-keen whiz-bang demos at JavaOne will get people magically writing Java Desktop apps again? What do you think?
Deployment done right
I really feel WebStart has about 90% of what is needed for "Deployment Done Right". Getting that last 10%, and getting more JDIC in the JRE is important.
+1 on everything
I've recently started to learn Cocoa, and I was blown away by the simplicity of the NIB file/Interface Builder pattern (I believe that this is possible with GTK/Glade (http://glade.gnome.org/) as well). It makes life so much easier to have your interface be a bunch of serialized objects waiting to be revived. It also makes GUI builders trivial to build, which greatly increases my confidence in the tool. It relieves my need to "check up" on the generated code since there is no generated code. I, too, don't see any overriding technical issue that would keep this from becoming a reality in the Swing world, and it would remove one more barrier to entry into Swing programming.