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 widgetsand programming to the core set from Java is identical across all the platforms.
Some Java developersand Sun itselfobject 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.
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.