Mustang Looks Promising for Java on the Desktop

• By Matt Stephens
• May 1, 2005

Java’s “official”, built-in UI toolkit, Swing, has had a difficult time over the years. It’s been derided as being slow, ugly and difficult to work with - which was true about 5 years ago. However it’s been making serious progress since then.

It’s true that Swing isn’t the simplest API to work with, meaning there’s a steep learning curve for newbies. But this isn’t because the API was badly designed, it’s because Swing is quietly, unassumingly powerful. If your desktop application has some peculiar needs, you can bet that Swing will provide a way to do it. It’s built from the ground up to be customizable.

Swing’s worst enemy is Sun’s marketing (in)ability. Marketing isn’t just about creating an image, a façade, it’s about shaping the product itself to reach the right audience. If Swing had been placed in the hands of, say, Macromedia (now part of Adobe), it’s a fair bet that Swing’s web browser integration would now be second-to-none. Were people to hear the name “Swing”, they would hear “dynamic web page”, “usability”, “rich client” and so forth. Instead, with Sun, people hear “clunky”, “slow” and “ugly” – in other words, 5-year-old news.

But hey, I’m getting all negative here (an unfortunate habit). Swing has been taking great bounds with each new release of Java. With the next big release (6.0, code-named Mustang), some serious shortcomings of the otherwise hugely powerful Swing are lining up to be fixed.

I’ve already blogged about the fix for the Gray Screen of Boredom (GSoB). But there’s a whole lot more already being promised for desktop Java in Mustang. Note that the improvements I describe below may be subject to change, but they represent the latest planned features that will have the greatest impact on Java on the desktop.

The Look & Feels are going to be improved (Swing has the chameleon-like ability to adapt its appearance and (to an extent) the way its components behave, without needing to reprogram or even recompile [or even restart] your application). On Windows XP, Swing will make more use of the native Windows API to render portions of components. This’ll naturally make Swing apps seem more “native”. Making Swing look native on Longhorn will also be a consideration; and a similar effort is also underway for GTK.

Drag & Drop will be made easier to work with (hurrah). Current D&D support in Swing is “sort of just good enough” yet appallingly difficult to work with.

Also there’ll be a new JTreeTable component (based on the work already done in JDNC) and an enhanced JTable providing sorting, filtering and highlighting support.

Some critical improvements are also being planned for AWT. AWT can be thought of as the unglamorous, workhorse underpinnings of Swing. It handles much of the interaction between the OS and the platform-neutral, “lightweight” Swing components. Components which use AWT directly (instead of being built on Swing) are called “heavyweight” components because they use native OS resources directly (e.g. third-party ActiveX components). Lightweight (Swing) and heavyweight (AWT) components have never worked well together. Heavyweight components are like schoolyard bullies, pushing their way in front of the more lightweight Swing components. However, for Mustang, Sun is promising to make lightweight and heavyweight components work better together.

Also important for Java on the Desktop, the excellent Java2D API will be getting its fair share of improvements. Not least, font antialiasing will (at last) get some serious attention, including better font smoothing on LCD screens, and fixing of current text rasterization bugs. At last, curved primitives will (so it’s promised) also be fixed. Could Java2D at last be able to draw a truly round circle?

Deployment also gets some serious attention to detail. Java Web Start (JWS), though a nice idea, has always suffered because the user experience can be pretty horrible at times. (I’ll blog about this separately sometime, because the usability issues with JWS could probably fill a whole article). With Mustang, one of the new features is specifically aimed at addressing the JWS user experience.

Some critical bugs remain tucked away out of the spotlight, e.g. applets don’t behave well in a layered DHTML page. Perhaps (in another 5 years or so?) Sun will turn their attention to these.

However, if Sun can genuinely deliver on all of the improvements planned for Mustang, Java is shaping up to look really good on the desktop. My only real complaint is that, although there’s some cool new stuff in there, many of these “improvements” are really fixes for age-old critical bugs, which should have been fixed years ago. Desktop Java gets better with each new release, but in many ways it’s also reaching a “minimum acceptance level” where cynics might now consider it just good enough for real-world use. It’s certainly taken a while.

Trouble is, is it too late already? For example, with early “bleeding edge” releases of Java 6.0 (Mustang) already available, I’m involved in a “rich client” project where we are just about to take the first tentative steps to move to Java 5.0 (Tiger). In a real-world project with actual customers, we can’t afford to be early adopters on the bleeding edge (prototypes and “fringe projects” notwithstanding). We have to wait for each version of Java to stabilize before we can seriously consider moving on up. Probably most Swing projects have similar real-world constraints.

But we could really, seriously do with some of Mustang’s promised critical bug fixes right now. Mustang can’t arrive soon enough for us. Other software developers might not be quite so patient, and might already be looking around to see what the competition has to offer.