15.29 Alternativen zu AWT und Swing 
Es gibt Anwendungsfälle, da wollen weder AWT noch Swing passen. Swing ist zwar sehr mächtig, doch kostet es auch viele Ressourcen. AWT ist zwar schlank und recht schnell, bietet aber wenig Komponenten. Sun zeigt auch bisher keine Ambitionen, das AWT weiterzuentwickeln. Das AWT ist bei Geräten mit wenig Speicher, etwa Handheld-Geräten, noch eine interessante Variante.
Für Webseiten müssen es jedoch oft nicht Applets mit AWT oder gar Swing-Komponenten sein. Eine einfache Mischung aus HTML und ein wenig JavaScript tun es auch. Auch Macromedia Flash ist als alternative Benutzungsschnittstelle eine Wahl, wenn Designer und Programmierer nicht beabsichtigen, Benutzungsschnittstellen-Komponenten ganz neu zu entwerfen. Flash ist plattformübergreifend und sehr stark verbreitet – fast jeder Client ist mit einem Flash-Plugin ausgestattet.
15.29.1 XML-Beschreibungen der Oberfläche: Swixml, XUL/Luxor 
Eine andere Philosophie ist die Trennung der Beschreibung der Benutzungsschnittstelle und der Logik. Zwar ist es ohnehin guter Stil, dies zu trennen, doch einen Schritt weiter geht die völlige Loslösung von Java und die Hinwendung zu einer externen Beschreibung von grafischen Oberflächen, etwa in XML. In der Java-Welt gibt es zwei populäre Implementierungen: Swixml und XUL. Microsoft erkennt ebenfalls die Notwendigkeit und arbeitet an XAML (Extensible Application Markup Language).
Swixml (http://www.swixml.org/) ist das Ergebnis einer XML-Abbildung von Wolf Paulus. Eine Swixml-Datei sieht in etwa folgendermaßen aus:
<?xml version="1.0" encoding="UTF-8"?>
<frame size="640,480" title="Hallo Welt"
DefaultCloseOperation="JFrame.EXIT_ON_CLOSE">
<panel constraints="BorderLayout.CENTER">
<label LabelFor="tf" text="Hallo Welt!"/>
<textfield id="tf" Columns="20" Text="Swixml"/>
<button Text="Klick mich" Action="submit"/>
</panel>
</frame>Swixml nutzt SAX und JDOM, um die XML-Datei einzulesen und zu repräsentieren und zur Laufzeit eine Swing-Anwendung darzustellen.
In eine andere Richtung geht XUL (XML User Interface Language), eine plattformunabhängige Beschreibung der GUI, die ursprünglich nur für Mozilla gedacht war; daher ist XUL auch unter http://www.mozilla.org/xpfe/ zu finden. Eine XUL-Datei mit einer Schaltfläche sieht ungefähr so aus:
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<window id="bsp" title="XUL-Beispiel"
xmlns:html="http://www.w3.org/1999/xhtml"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<button id="open-button" label="Klick mich"/>
</window>Die Umsetzung dieser XUL-Dateien übernimmt ein Konverter wie Luxor (http://luxor-xul.sourceforge.net/). Das Ergebnis ist wieder eine Oberfläche in Swing.
Weitere Lösungen wie Thinlet, GUI Builder und Ibex sind auf http://xul.sourceforge.net/ aufgelistet.
15.29.2 SWT (Standard Widget Toolkit)
Im Jahr 1998 begann IBM mit der Entwicklung des Nachfolgers von »VisualAge for Java« (in Smalltalk geschrieben). Für die neue Entwicklungsumgebung – aus der später Eclipse wurde – benötigte das Entwicklungsteam Oberflächenelemente. Swing war weit davon entfernt, zügig, speichereffizient und korrekt zu sein, und Sun hat die AWT-Entwicklung nicht erkennbar weitergeführt. So entschied IBM, mit dem SWT (Standard Widget Toolkit) eine Alternative zum AWT zu entwickeln, das Möglichkeiten eines nativen grafischen Systems nutzen kann. Dazu zählen neben Komponenten wie Schaltflächen und Tabellen auch integriertere Teile wie Drag & Drop, Zwischenablage, Drucken und ActiveX-Integration (unter Windows). Dabei nutzt SWT keinen Anteil von AWT, nicht einmal die grafischen Primitivoperationen oder Java 2D. Wegen dieser engen Kopplung an das System müssen die SWT-Applikationen mit einer dynamischen Bibliothek (DLL unter Windows) ausgeliefert werden. Eine Umsetzung gibt es heute neben Windows (auch Windows CE) und MacOS X etwa auf diversen Motif-Plattformen, GTK (kein Qt) und QNX/Photon. (Wer nur unter GNOME und GTK+ programmiert, der sollte einen Blick auf Java-GNOME unter http://java-gnome.sourceforge.net/ werfen.)
Ursprünglich war das SWT (http://www.eclipse.org/swt/) ausschließlich für die neue Entwicklungsumgebung gedacht. Mittlerweile erfreut sich die Swing-Alternative aber größerer Beliebtheit und ist inzwischen von der Entwicklungsumgebung losgelöst. Insbesondere für mobile Endgeräte (Windows CE) ist das SWT sehr performant, da die Bibliothek auf einem kleinen nativen Kern aufbaut und recht leichtgewichtig ist. Die Eclipse Rich-Client-Platform (RCP) ist ein großes Rahmenwerk für komplexe grafische Oberflächen auf der Basis von SWT, was Aufgaben wie Konfigurationen für Benutzer oder Verteilung und Aktualisierung von Haus aus realisieren.
Das immer wieder vorgebrachte Argument, dass mit SWT die Java-Oberflächen genauso aussehen wie native Oberflächen der jeweiligen Plattform, ist fragwürdig. SWT-Oberflächen sehen anders aus, etwa bei den Reitern oder Menüs, und Swing kommt dem nativen Aussehen – insbesondere mit Java 6 auf Windows – eigentlich näher. Dem Anwender ist das ziemlich egal. Selbst für konservativere Bereiche wie Office haben sich Anwender daran gewöhnt, dass Microsoft in jeder Produktversion die Optik anpasst und Microsoft Office 2007 nun völlig anders aussehen lässt. Office 12 sieht wieder ganz anders aus als der Windows Media Player, und Letzterer anders als die MSN Encarta – drei Anwendungen von Microsoft (von den optischen Änderungen der grafischen Oberfläche war noch gar nicht die Rede). Die Avantgarde der Anwender passte schon immer die Oberflächen an; das »Skinning« unterstützen heute bereits viele Anwendungen, egal, ob sie Winamp oder Yahoo! Messenger heißen.
Ob die IBM-Entwickler mit dem mittlerweile schnellen Swing-Framework die gleiche Entscheidung treffen würden, wird immer wieder diskutiert, so wie die Frage, ob Swing irgendwann einmal Eclipse realisiert. Von der Geschwindigkeit und dem Speicherverbrauch her wäre es denkbar, aber sehr unwahrscheinlich, dass die Entwickler Mühe für eine Umstellung investieren. Zumal in SWT auch Swing-Applikationen und Java 2D zum Laufen gebracht werden können.
SwingWT
Normalerweise nutzt Swing zur Darstellung der Komponenten die Grundeigenschaften von AWT: mit einem Stift in einer Farbe kann auf eine Oberfläche gezeichnet werden. SwingWT (http://swingwt.sourceforge.net) versucht eine Abbildung der Swing- und AWT-Komponenten und weitere Zeicheneigenschaften auf SWT.