Tuesday, November 20, 2007

The Java GUI Toolkit Flatline

We are seeing the transformation of the client into an incredibly rich personal experience.

AJAX, RIA and other Web 2.0 technologies are driving new paradigms in the browser, while Windows Presentation Foundation (WPF) is similarly improving desktop GUI experiences on Wintel systems. One technology that has not participated in this revolution is Java. In fact, it’s hard to recall any major stories regarding Java’s built-in Swing toolkit or IBM’s competing Standard Widget Toolkit (SWT). I find this curious, because we all remember how just a few years ago the rivalry between these two camps was intense. Since then, the smoke has cleared, and we see that the fires of innovation in both camps are on a very low flame.

Swing, as most of you will recall, came out in 1998 with much fanfare as part of the Java 1.2 release. Its claim was remarkable breadth of functionality and a nearly infinite configurability. Any interface need of that period—no matter how complex—could be done in Swing. And because Swing was skinnable, it could be made to approximate the look and feel of Windows, Motif and other interfaces. But Swing had drawbacks: At the time it was slow and its emulation of native widgets and controls was far from faithful. Moreover, Swing was difficult to program.

In response, IBM developed SWT. The defining aspects of SWT were the use of native widgets and simplicity of programming. In exchange, it gave up the full complement of functionality that Swing offered. Because the primary use case for SWT was the Eclipse IDE, the features left behind (such as truly rich text) were not likely to be terribly missed.

When SWT came out, it was indeed faster than Swing, and it used native widgets. Shortly, the JFace library appeared, which expanded SWT’s power by providing higher-level constructs, while still allowing direct access to the lower-level controls.

Since then, though, progress has consisted primarily of refining the underlying technology rather than advancing it, and porting to new platforms. Swing, for example, now runs very fast and has an interface that is faithful to underlying look and feel. If today’s Swing had been available when IBM began getting serious about Eclipse, I doubt SWT would have been funded or needed.

SWT has not advanced much. Nor has IBM done much to encourage its use outside of the Eclipse environment. At one time, developers were expecting a great flow of SWT apps, so that we’d have a Swing/SWT rivalry akin to the GTK versus Qt competition in the Linux world. But the large flow of SWT apps never materialized. Most SWT apps are plug-ins to Eclipse, with a few notable standalone items, but certainly not many. One factor, perhaps, is that the SWT native-widget approach occasionally runs into difficulties: A common complaint of Linux users of Eclipse is how poorly the interface works when running on GTK widgets.

Trolltech recently attempted to deliver its innovations to Java desktop clients by releasing Qt Jambi, a Java wrapper for its remarkable Qt C++ library. This implementation works fine—its functionality is slightly greater than Swing’s and its ease of use is comparable to SWT. The question is whether programmers will pay US$1,500 or more per target platform to develop with Jambi. (The library is royalty-free.) The big advantage of Jambi is the company behind it: Trolltech develops only UIs, so more than either Sun or IBM, it will push forward with product features.

The company that is innovating the most in UI interface design on desktops is not Apple, nor the Java folks, but, rather, Microsoft. Say what you will about the company’s past UI efforts, but you cannot deny the improvement in Windows Vista nor the constant revving of widgets and controls that occurs with each release of Office. The trouble is that none of today’s visual wizardry (and Microsoft Office definitely has some very interesting graphics features) is as elegant as NextStep was 10 years ago. Even Apple is still a full step behind NextStep on the desktop.

There are movements afoot to try to integrate Swing and SWT, but I don’t know how much real enthusiasm there is for convergence. Each constituency is content with what it has. These projects mostly try to make it possible to run Swing components in Eclipse. Surely, that’s a worthwhile goal, but not anything that will push forward the state of the art. Odd as it might seem, for Java to advance on the desktop, we need the willingness to invest in the GUI that Microsoft has exhibited, Apple’s panache, and for Java to find a common ground. And so, I expect truly great UIs are not an immediate part of Java’s future.

courtesy @sdtimes.com

No comments: