10Grafische Oberflächen mit Swing 
»Jedenfalls ist es besser, ein eckiges Etwas zu sein
als ein rundes Nichts.«
– Friedrich Hebbel (1813–1863)
10.1AWT, JavaFoundation Classes und Swing
10.1.1Das Abstract Window Toolkit (AWT)
Ein Urgestein der Java-Bibliothek ist das Das Abstract Window Toolkit (AWT); es steht auf gleicher Stufe wie die Klassen-Oldies Object und String. Die GUI-Bibliothek bietet Methoden für die Primitivoperationen zum Zeichnen, zur Ereignisbehandlung und einen Satz von GUI-Komponenten.
Peer-Klassen *
Eine Besonderheit des AWT ist, dass es jede grafische Komponente in Java auf eine Komponente der darunterliegenden Plattform abbildet. Dazu bedient sich das AWT so genannter Peer-Klassen, also Partnern auf der Seite der speziellen Benutzeroberfläche. Eine Schaltfläche unter AWT leitet somit die Visualisierung und Interaktion an eine Peer-Klasse auf der Betriebssystemseite weiter. Damit sehen AWT-Anwendungen unter Windows so aus wie jede andere Windows-Anwendung, und für Anwendungen unter Mac OS oder X11 gilt das Gleiche.
Die Partner haben Vor- und Nachteile:
Durch die nativen Peer-Klassen verhält sich die Oberfläche exakt so wie erwartet und ist optisch nicht von anderen nativen Programmen zu unterscheiden.
Leider zeigen die Programme unter den verschiedenen Betriebssystemen bisweilen merkwürdige Seiteneffekte. So kann ein Textfeld unter Windows weniger als 64 KiB Zeichen aufnehmen, bei anderen Oberflächen ist dies egal.
Da das AWT auch nur Komponenten anbietet, die auf jeder Plattform verfügbar sind, ist das Angebot an Widgets sehr beschränkt. Moderne grafische Elemente, sei es auch nur ein Icon auf einer Schaltfläche, bietet das AWT nicht an, und sie müssen neu geschrieben werden.
Da jede AWT-Komponente Ressourcen von der nativen Plattform bezieht und diese außerhalb der Speicherverwaltung von Java liegen, nennen sich diese Komponenten schwergewichtige Komponenten (engl. heavyweight components).
10.1.2Java Foundation Classes (JFC)
Obwohl das Abstract Window Toolkit das Problem einer einheitlichen Benutzeroberfläche lösen sollte, ist dies Sun damals nicht ganz gelungen. Das AWT war von Anfang an zusammengepfuscht. So meinte auch James Gosling, Vater von Java:
»The AWT was something we put together in six weeks to run on as many platforms as we could, and its goal was really just to work. So we came out with this very simple, lowest-common-denominator thing that actually worked quite well. But we knew at the time we were doing it that it was really limited. After that was out, we started doing the Swing thing, and that involved working with Netscape and IBM and folks from all over the place.«[ 95 ](Das Interview vom 24. März 1998 ist leider nicht mehr online – Oracle hat die Seite gelöscht.)
Nicht nur das das Design ist schwach, auch lassen sich professionelle Oberflächen mangels leistungsfähiger Komponenten nicht erstellen. Daher sind für die Abkürzung AWT noch einige hämische Deutungen im Umlauf: »Awful Window Toolkit«, »Awkward Window Toolkit« oder »Annoying Window Toolkit«.
Da Sun das AWT einfach hielt, Entwickler von Oberflächen jedoch immer einen unstillbaren Hunger nach Komponenten haben, konzipierte Netscape die Internet Foundation Classes (IFC), die das AWT in wesentlichen Punkten ergänzten. Im April des Jahres 1997 einigten sich Sun, Netscape und IBM auf eine GUI-Bibliothek, die auf Netscapes IFC aufbaut und das AWT erweiterte; der Name des Toolkits: JFC(Java Foundation Classes). Die JFC waren zunächst als Ergänzung zu Java 1.1 entwickelt worden, flossen dann aber als fester Bestandteil in Java 1.2 ein, wo sie heute noch einen festen Platz einnehmen.
Bestandteile der Java Foundation Classes
Die Java Foundation Classes bestehen im Wesentlichen aus:
GUI-Komponenten: Unter die so genannten Swing-Komponenten fallen ganz neue grafische Elemente. Diese sind, anders als die plattformabhängigen Peer-Komponenten des herkömmlichen AWT, fast vollständig in Java implementiert.
Pluggable Look & Feel: Dies gibt uns die Möglichkeit, das Aussehen der Komponenten zur Laufzeit zu ändern, ohne das Programm neu zu starten. Alle Komponenten des Swing-Sets haben diese Fähigkeit automatisch.
Java 2D API: Die 2D-Klassenbibliothek ist eine neue Technik, die über eine Objektbeschreibung – ähnlich wie PostScript – Objekte bildet und diese auf dem Bildschirm darstellt. Zu den Fähigkeiten der Bibliothek gehört es, komplexe Objekte durch Pfade zu bilden und darauf Bewegungs- und Verschiebeoperationen anzuwenden.
Drag & Drop: Daten können mittels Drag & Drop leicht von einer Applikation zur anderen übertragen werden. Dabei profitieren Java-Programme auch davon, Daten zu nutzen, die nicht aus Java-Programmen stammen.
Accessibility (Unterstützung für Menschen mit Behinderungen): Diese API erlaubt mit neuen Interaktionstechniken den Zugriff auf die JFC- und AWT-Komponenten. Zu diesen Techniken zählen unter anderem Lesegeräte für Blinde, eine Lupe für den Bildschirm und auch die Spracherkennung.
Swing-Komponenten sind ein wesentlicher Bestandteil der JFC, und oft wird in der Öffentlichkeit »Swing« als Synonym für JFC verstanden.
Warum Swing Swing heißt
Als 1997 in San Francisco auf der JavaOne die neuen Komponenten vorgestellt wurden, entschied sich Georges Saab, ein Mitglied des JFC-Teams, für Musik parallel zur Präsentation, und zwar für Swing-Musik, weil der Entwickler glaubte, dass sie wieder in Mode käme. Dementsprechend wurden die neuen grafischen Elemente in einem Paket namens Swing abgelegt. Obwohl der Name offiziell dem Kürzel JFC weichen musste, war er doch so populär, dass er bestehen blieb.
Leichtgewichtige Swing-Komponenten
Eine Leichtgewicht-Komponente (engl. lightweight component) verfügt über keinen Peer, also über keine direkte Repräsentation im Fenstersystem. Somit gibt es keine speziellen Implementierungen des Systems beispielsweise auf Windows, Mac OS oder X11. Alle Komponenten werden mit primitiven Zeichenoperationen gemalt, so etwa eine Schaltfläche aus einem Rechteck mit Schatten und einem Text in der Mitte. Ein Vorteil: Eine Leichtgewicht-Komponente kann durchsichtig sein und muss nicht mehr in einen rechteckigen Bereich passen. Da alle Komponenten nun gemalt werden, lässt sich alles ohne Rücksicht auf das zugrunde liegende grafische System zeichnen. Dieser Weg ist also plattformunabhängiger, aber nutzt nicht unbedingt alle optimalen Möglichkeiten, wie zum Beispiel Antialiasing, des Betriebssystems oder die Möglichkeiten einer Plattformkomponente, wie den komplexeren Dateiauswahldialog.
Während viele Swing-Komponenten gar keine Beziehung zu schwergewichtigen AWT-Komponenten haben, gilt das nicht für alle. Ein javax.swing.JFrame basiert zum Beispiel auf der AWT-Komponente java.awt.Frame, denn JFrame ist eine Unterklasse von Frame.
Übersicht über Swing-Komponenten
Swing-Komponente | Klassenname |
|---|---|
 | JLabel |
 | JButton |
 | JCheckBox |
 | JRadioButton |
 | JTextField |
 | JPasswordField |
 | JComboBox |
 | JScrollBar |
 | JSlider |
 | JSpinner |
 | JProgressBar |
 | JList |
 | JTabbedPane |
 | JToolBar |
 | JMenu |
 | JScrollPane |
 | JTree |
 | JTable |
 | JEditorPane |
Tabelle 10.1Die Swing-Komponenten und Klassennamen
SwingSet-Demos
Um sich einen Überblick über die Swing-Komponenten zu verschaffen, stellt Oracle ein interessantes Swing-Demo über die Technologie WebStart im Internet zur Verfügung. Setzen wir die URL http://download.java.net/javadesktop/swingset3/SwingSet3.jnlp in den Browser, laden wir die JNLP-Datei, und nach dem Start wird Java beginnen, das Program zu laden und auszuführen.
Abbildung 10.1SwingSet3 Demo
10.1.3Was Swing von AWT-Komponenten unterscheidet
AWT bzw. die Java Foundation Classes bilden mit Ereignisbehandlung, Fenster-Management und einer mächtigen 2D-API das Fundament. Die Swing-Komponenten setzen auf dem AWT auf und sind somit eng damit verbunden. Sie sind in der Regel selbst in Java implementiert, wobei es Optimierungen gibt, dass wie im Fall von Windows das Betriebssystem selbst nativ die Komponenten zeichnet. Wir haben dazu schon die Begriffe leichtgewichtige und schwergewichtige Komponenten eingeführt.
Während das AWT an die Partnerkomponenten des darunterliegenden grafischen Systems gebunden ist, ist Swing flexibler, weil es alle Komponenten beliebig selber zeichnen kann. Daraus ergibt sich viel Flexibilität, etwa:
Swing-Schaltflächen und Beschriftungen nehmen Symbole auf, die sie beliebig um Text angeordnet darstellen. So etwas bietet AWT nicht, in Swing ist es möglich.
Das AWT bietet keine komplexen Komponenten wie Tabellen oder Bäume. Swing integriert diese sehr leistungsfähigen grafischen Elemente und bildet die komplette Logik in Java nach, ohne auf irgendeinen Programmcode vom nativen Betriebssystem zurückzugreifen.
Jede Swing-Komponente kann einen Rahmen bekommen; eine Schaltfläche kann wie unter Mac OS X abgerundet sein.
Swing-Komponenten können transparent und beliebig geformt sein.
Neben der reinen Optik gibt es noch andere Unterschiede:
AWT-Komponenten nehmen alle Daten auf und kümmern sich um die Darstellung. Swing ist in dieser Hinsicht moderner, weil es nach dem Model-View-Prinzip Daten getrennt von den Komponenten hält, sodass beide Teile unabhängig weiter entwickelt werden können.
Die AWT-Methoden sind threadsicher, es können also mehrere Threads zur gleichen Zeit Methoden der AWT-Komponenten aufrufen. Die meisten Swing-Methoden sind nicht threadsicher, und Entwickler müssen darauf achten, dass Parallelität keine problematischen Zustände erzeugt.
