9.29 Alternativen zu programmierten Oberflächen, AWT und Swing *

Dass Swing-Oberflächen immer programmiert werden müssen, hält auf, auch wenn ein GUI-Builder heutzutage die Schmerzen minimiert. Um in die Richtung von deklarativen Oberflächen zu kommen, gibt es unterschiedliche Open-Source-Lösungen, da Oracle nichts im Angebot hat.

Es gibt Anwendungsfälle, in denen 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 wenige Komponenten. Oracle 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, aber es sieht so aus, als ob die Entwicklung bei JavaFX Script weitergeht. JavaFX erlaubt auch deklarative Oberflächen. Während AWT und Swing aufeinander aufbauen, ist JavaFX völlig neu entworfen und komplett unabhängig. Eine weitere Möglichkeit ist SWT, was durch Eclipse bekannt wurde. Es ist interessant, weil mit der Eclipse RCP eine ausgereifte Möglichkeit zur Entwicklung von Desktop-Programmen geschaffen wurde.

Ein ganz anderer Trend zeigt in die Richtung HTML5: Eine Mischung aus HTML mit CSS und JavaScript tut es auch.

9.29.1 Deklarative Beschreibungen der Oberfläche: Swing JavaBuilder, Swixml

Eine andere Philosophie ist die Trennung der Beschreibung der Benutzerschnittstelle und der Logik. Zwar ist es ohnehin guter Stil, diese zu trennen, doch einen Schritt weiter geht die völlige Loslösung von der Programmierung in Java für den Aufbau des Komponentenbaums und die Hinwendung zu einer externen Beschreibung von grafischen Oberflächen, etwa in XML oder YAML.

Swing JavaBuilder

Eine aktuelle Lösung zur deklarativen Beschreibung von Swing-Obeflächen bietet der Swing JavaBuilder (http://code.google.com/p/javabuilders/). Die Open-Source-Bibliothek steht unter der Apache-Lizenz und nutzt statt XML das kompaktere YAML-Format, dessen Schreibweise noch weiter verkürzt wurde. Das PDF-Tutorial gibt ein Beispiel:

JFrame(name=frame, title=frame.title, size=packed, defaultCloseOperation=exitOnClose):
  – JButton(name=save, text=button.save, onAction=[$validate,save,done])
  – JButton(name=cancel, text=button.cancel, onAction=[$confirm,cancel])
  – MigLayout: |
    [pref] [grow,100] [pref] [grow,100]
    "label.firstName" txtFirstName "label.lastName" txtLastName
    "label.email" txtEmail+*
    >save+*=1,cancel=1
bind:
  – txtFirstName.text: person.firstName
  – txtLastName.text: person.lastName
  – txtEmail.text: person.emailAddress
validate:
  – txtFirstName.text: {mandatory: true, label: label.firstName}
  – txtLastName.text: {mandatory: true, label: label.lastName}
  – txtEmail.text: {mandatory: true, emailAddress: true, label: label.email}

Dazu kommt eine Java-Klasse, die die YAML-Datei referenziert und die Ereignisbehandler realisiert, also etwa die save()-Methode anbietet. Jetzt fehlt nur noch ein toller GUI-Builder.

Swixml und XUL

Swixml nutzt das XML-Format zur Beschreibung von GUIs. Eine Swixml-Datei sieht 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 um zur Laufzeit eine Swing-Anwendung darzustellen. Zugriff auf das Objektgepflecht liefert dann eine Anweisug wie diese:

new SwingEngine( this ).render( "datei.xml" )

Das Ergebnis wäre in unserem Fall in JFrame.

Die Folien unter http://www.swixml.org/slides.html geben einen Einblick in die Möglichkeiten.

9.29.2 SWT (Standard Widget Toolkit)

Im Jahr 1998 begann IBM mit der Entwicklung des Nachfolgers von VisualAge for Java (das in Smalltalk geschrieben war). Für die neue Entwicklungsumgebung – aus der später Eclipse wurde – benötigte das Entwicklerteam Oberflächenelemente. Swing war weit davon entfernt, zügig, speichereffizient und korrekt zu sein, und Sun hat schon damals die AWT-Entwicklung nicht erkennbar weitergeführt. So entschied IBM, mit dem SWT (Standard Widget Toolkit) eine Alternative zum AWT zu entwickeln, die Möglichkeiten eines nativen grafischen Systems nutzen kann. Dazu zählen neben Komponenten wie Schaltflächen und Tabellen auch integriertere Fähigkeiten 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 außer für Windows (auch Windows CE) und Mac OS 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 Framework für komplexe grafische Oberflächen auf der Basis von SWT, das Aufgaben wie Konfigurationen für Benutzer oder Verteilung und Aktualisierung von Haus aus realisiert.

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 ab Java Version 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 wirkt 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 werden, wird immer wieder diskutiert – ebenso 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 in 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 das SWT, sodass sich etwa Komponentenbibliotheken einfach in Eclipse RCP-Projekte einbinden lassen. Das letzte Update stammt von August 2007.

SWTSwing

Während SwingWT das AWT und Swing auf SWT bringt, nimmt sich ein anderes Projekt genau die andere Richtung vor: SWTSwing (http://swtswing.sourceforge.net/) portiert SWT auf Swing. So wäre es prinzipiell möglich, Eclipse ohne native Bibliotheken unter 100 % purem Java laufen zu lassen. Allerdings ist auch die Entwicklung im August 2007 stehen geblieben. Welch Zufall dass es wie SwingWT ebenfalls im August 2007 endete.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.