he Java world has a new toy called SWT (the Standard Widget Toolkit), created by IBM and integrated with the Eclipse development environment. SWT is a platform-specific runtime that exposes “widget” objects such as text boxes, scrollbars, and other familiar GUI controls to Java developers, but uses JNI to make native code calls to create and interact with those controls. Using SWT, Java developers can build responsive GUI applications that are essentially indistinguishable from native platform GUIs.

That’s not to say that SWT applications aren’t cross-platform; they are (mostly). There are SWT implementations for Windows (Win32), Windows CE, Motif (Linux, AIX, HP/UX, Solaris), GTK (Linux), and several others. The SWT runtime changes when you run your application on these different operating systems, but as long as your application code uses standard widgets it can run unchanged. (Not all implementations are feature-complete; you can check the current status at Eclipse.org.) Sure, some platforms have widgets and capabilities that others don’t have, but all the implementations include a core set of widgets?and programming to the core set from Java is identical across all the platforms.

Some Java developers?and Sun itself?object to SWT because it ties applications to platform-specific code, thus breaking the cross-platform nature of applications written without such dependencies-?such as those written with Swing. But many developers eschew the purist attitude and are using SWT anyway because it improves the performance of Java applications, making them more competitive with applications targeted to specific platforms.

The developers on the Mozilla project, faced with a similar problem?how to create a cross-platform browser?came up with a different type of solution, called XUL (XML-based User Interface Language), which uses an XML-formatted language to define a description of the interface objects. That’s the first big difference between XUL and SWT. While both define “widgets,” the SWT implementation includes the code to create and activate the widgets, while XUL simply describes them. In Mozilla, you can control the interface elements with C, C++, Python, or JavaScript, and you can control the appearance or style of the widgets using CSS (Cascading Style Sheets).

So far, SWT implementations target desktop applications, while Mozilla’s XUL currently targets browser-based applications. But there’s no real reason why they have to remain in those niches; both are ways to describe and activate controls. It doesn’t really matter whether those controls run in a browser or in a desktop application.

Open Source, Cross-platform
Both XUL (Netscape and Mozilla Public Licenses) and SWT (Common Public License) are open source cross-platform technologies; anyone is free to implement the specifications in any language and on any platform they prefer. Even though SWT is currently available only for use with Java, there’s no reason for that to continue; it would be perfectly possible for IBM or some other organization to create .NET-compatible (CLR-compatible) versions. If that happened, we would see Microsoft, IBM, and Sun each with a big piece of the development pie; Microsoft with the CLR, Sun with Java, and IBM with the cross-platform desktop connection for both .NET and Java.

So, naturally, for anyone anticipating a fully cross-platform .NET development environment, the question becomes: What are the open source .NET projects, Rotor and Mono, planning for GUI development? As it turns out, both projects are implementing the Windows.Forms namespace (which is not part of the CLR) on their respective platforms. As far as I can tell, neither project is attempting to use any alternative GUI representation. That could be a mistake. It’s going to be a huge effort to get the Windows.Forms namespace implemented on any particular platform, and that effort isn’t going to translate easily to any other platform, nor will the resulting forms translate easily to other languages.

In contrast, both SWT and XUL have already been implemented, at least experimentally, on several platforms, so the technology is already proven even if it’s not yet used extensively. Because both SWT and XUL specifications are open source, any alternative CLR implementation should be able to tap into the code of either one far more easily than performing a complete feature-for-feature rewrite of Windows Forms.

Moreover, any CLR/SWT or CLR/XUL implementation would also conceivably run on Windows, which would give current Windows developers an incentive to use it and would bring Java and .NET that much closer together.

To the Swift Go the Spoils
Frankly, I’m surprised that Microsoft didn’t include the Windows Forms specification in the CLR, as they’ve now created an opening for IBM, Mozilla, or another third party to provide an alternative GUI model that works not only across platforms but is also relatively independent of the language used to activate it.

Further, if Mozilla were to take on the project of connecting XUL to SWT, developers could design cross-platform GUIs in a completely language-independent fashion. For example, by designing an application interface in XUL and using the appropriate platform-specific SWT implementation to activate it in the language of your choice, the only thing you’d need to change from one platform to another would be the SWT runtime. It’s a powerful combination and opens a window of opportunity for any organization with the vision to implement it.

I doubt that Microsoft will leave the window open long; the company has been discussing a unified forms model for years. Further, Microsoft has experience generating XML-based forms in .NET, and while its model has not been adopted universally, it would be relatively easy for it to switch to some other XML representation. Obviously, Sun is in much the same shape. With SWT, platform-specific code has obtained a toehold in the otherwise unmarred surface of pure Java. There’s been a good deal of discussion about whether Sun should embrace SWT, although so far, they’ve clung to Swing tenaciously.

Meanwhile others are also looking at ways to improve Java’s GUI capabilities. At least two attempts have already been made at delivering XUL-specified interfaces to desktop machines. Martin Weindel’s Luxor XUL marries XUL to SWT for Linux and Java. Another project, XWT, provides a browser-based XUL rendering engine as both an ActiveX control (IE) and a Java applet. Marc Erickson, Project Manager, OTI Marketing and Sales (of OTI Embedded Systems), says OTI Labs has done similar work for the embedded community in an offering called P3ML. So there’s at least some movement in the development community.

Although these projects point the way to truly cross-platform GUIs, a broadly successful effort will need multi-vendor buy-in and support. The XWT FAQ presents the arguments for using XUL and discusses some problems.

Developers don’t need multiple programming models for common widgets, such as windows, list controls, outline controls, drop-down menus, textboxes, and buttons. Widgets act much the same between platforms and the differences that do exist lie almost exclusively in the look and feel (how they’re rendered and the events they raise). In short, the enormous efforts expended by developers who learn more than one GUI programming model interface are largely wasted, because the results are visually and functionally nearly identical yet remain quite different from a development point of view. I fully expect that an XML-based forms description language, backed by platform-specific, high-performance runtimes will eventually capture both the market and developers’ mindshare.