35.1 Eigenschaften und Architektur von Swing

• 35.1 Eigenschaften und Architektur von Swing
  • 35.1.1 Einleitung
  • 35.1.2 Eigenschaften von Swing
    • Leichtgewichtige Komponenten
    • Pluggable Look-and-Feel
    • Das Model-View-Controller-Prinzip
    • Aber...
  • 35.1.3 Wie geht es weiter?

35.1.1 Einleitung

Bereits kurze Zeit nachdem mit dem JDK 1.0 das Abstract Windowing Toolkit eingeführt wurde, begannen die Entwickler bei SUN, über Möglichkeiten nachzudenken, die graphische Oberfläche von Java-Anwendungen zu verbessern. Als nachteilig sahen sie vor allem folgende Eigenschaften des AWT an:

• Da alle Fenster- und Dialogelemente von dem darunterliegenden Betriebssystem zur Verfügung gestellt wurden, war es sehr schwierig, plattformübergreifend ein einheitliches Look-and-Feel zu realisieren. Die Eigenarten jedes einzelnen Fenstersystems waren für den Anwender unmittelbar zu spüren.
• Durch die Abhängigkeit von den betriebssystemspezifischen Komponenten erwuchsen den JDK-Entwicklern erhebliche Portierungsprobleme. Dadurch mußte teilweise viel Aufwand getrieben werden, um das Verhalten der Komponenten auf den unterschiedlichen Plattformen in hinreichendem Maße anzugleichen.
• Zudem gibt es im AWT nur eine Grundmenge an Dialogelementen, mit denen sich aufwendige grafische Benutzeroberflächen nicht oder nur mit sehr viel Zusatzaufwand realisieren ließen.

Erklärtes Ziel der JDK-Entwickler war es, diese Nachteile zu beseitigen und mit der Entwicklung der Java Foundation Classes (deren wichtigster Bestandteil die als Swing bezeichnete Sammlung grafischer Dialogelemente werden sollte) eine echte Alternative zum AWT zu schaffen.

35.1.2 Eigenschaften von Swing

Leichtgewichtige Komponenten

Im Gegensatz zum AWT benutzen Swing-Komponenten nur noch in sehr eingeschränkter Weise plattformspezifische GUI-Ressourcen. Abgesehen von Top-Level-Fenstern, Dialogen und grafischen Primitivoperationen werden alle GUI-Elemente von Swing selbst erzeugt. Ein Swing-Button unter Windows wird nicht mehr vom Windows-UI-Manager dargestellt, sondern von Swing selbst gezeichnet.

Diese Vorgehensweise bietet einige Vorteile:

• Erstens fallen die plattformspezifischen Besonderheiten weg, und der Code zur Implementierung der Dialogelemente vereinfacht sich deutlich.
• Zweitens entfallen auch die Unterschiede in der Bedienung. Der Anwender findet auf allen Betriebssystemen dasselbe Aussehen und dieselbe Bedienung vor.
• Drittens ist Swing nicht mehr darauf angewiesen, Features auf der Basis des kleinsten gemeinsamen Nenners aller unterstützten Plattformen zu realisieren. Komplexe Dialogelemente wie Bäume, Tabellen oder Registerkarten können plattformunabhängig realisiert werden und stehen nach der Implementierung ohne Portierungsaufwand auf allen Systemen zur Verfügung. Tatsächlich stellt Swing eine sehr viel umfassendere und anspruchsvollere Menge an Dialogelementen als das AWT zur Verfügung.

Der Grundstein für Komponenten, die von Java selbst erzeugt und dargestellt werden können, wurde im JDK 1.1 mit der Einführung der Lightweight Components (»leichtgewichtige« Komponenten) gelegt. Dabei wird die paint-Methode eines Component-Objects nicht mehr an die betriebssystemspezifische Klasse weitergeleitet, sondern in den Komponentenklassen überlagert und mit Hilfe grafischer Primitivoperationen selbst implementiert. Die im AWT vorhandenen Dialogelemente werden im Gegensatz dazu als Heavyweight Components bezeichnet (»schwergewichtige« Komponenten).

Mit Hilfe der leichtgewichtigen Komponenten, die für alle Aspekte der Darstellung selbst verantwortlich sind, konnten einige interessante Features realisiert werden. So können beispielsweise zu allen Komponenten Tooltips erzeugt werden (also kleine Hilfetexte, die über der Komponente beim Verweilen mit der Maus angezeigt werden), ohne daß dazu Unterstützung seitens des zugrunde liegenden Grafikbetriebssystems erforderlich wäre.

Eine andere Eigenschaft, die nur mit Hilfe leichtgewichtiger Komponenten realisiert werden konnte, wird als Debug-Grafik bezeichnet. Dabei wird der Darstellungsvorgang beim Zeichnen der Komponente künstlich so verlangsamt, daß er wie in einer Zeitlupeneinstellung Schritt für Schritt verfolgt werden kann. Das ist insbesondere während der Entwicklung eigener Komponenten nützlich, um den Bildaufbau studieren und auf Fehler hin untersuchen zu können.

Pluggable Look-and-Feel

Die Swing-Entwickler gingen aber noch einen Schritt weiter. Eine der auf den ersten Blick spektakulärsten Eigenschaften von Swing ist die Möglichkeit, das Look-and-Feel (also das Aussehen und die Bedienung einer Anwendung) zur Laufzeit umzuschalten. Dieses als Pluggable Look-and-Feel bezeichnete Feature ermöglicht es beispielsweise einem Windows-Anwender, zwischen drei unterschiedlichen Look-and-Feels zu wählen (Swing, Motif und Windows).

Dabei muß die Entscheidung für oder gegen ein bestimmtes Look-and-Feel keineswegs bereits zum Design- oder Entwicklungszeitpunkt getroffen werden. Vielmehr wurden alle Swing-Komponenten so entworfen, daß es möglich ist, das Look-and-Feel einer Anwendung zur Laufzeit umzuschalten. Das Programm besitzt dazu typischerweise einen speziellen Menüpunkt oder eine Konfigurationsmöglichkeit, die es dem Anwender ermöglicht, ein Look-and-Feel nach seinem Geschmack auszuwählen. Das Programm selbst muß praktisch keinen zusätzlichen Aufwand treiben, denn das Umschalten wird nach einem einzigen Methodenaufruf von einem User-Interface-Manager erledigt, der alle nötigen Maßnahmen koordiniert ausführt.

Das Model-View-Controller-Prinzip

Neben den äußerlichen Qualitäten wurde auch die Architektur des Gesamtsystems verbessert. Wichtigste "Errungenschaft" ist dabei das Model-View-Controller-Prinzip (kurz MVC genannt), dessen Struktur sich wie ein roter Faden durch den Aufbau der Dialogelemente zieht. Anstatt den gesamten Code in eine einzelne Klasse zu packen, werden beim MVC-Konzept drei unterschiedliche Bestandteile eines grafischen Elements sorgsam unterschieden:

• Das Modell enthält die Daten des Dialogelements und speichert seinen Zustand.
• Der View ist für die grafische Darstellung der Komponente verantwortlich.
• Der Controller wirkt als Verbindungsglied zwischen beiden. Er empfängt Tastatur- und Mausereignisse und stößt die erforderlichen Maßnahmen zur Änderung von Model und View an.

Das Modell enthält praktisch die gesamte Verarbeitungslogik der Komponente. Ein wichtiger Aspekt ist dabei, dass ein Model mehrere Views gleichzeitig haben kann. Damit Veränderungen des Modells in allen Views sichtbar werden, wird ein Benachrichtigungsmechanismus implementiert, mit dem das Modell die zugeordneten Views über Änderungen informiert. Diese Vorgehensweise entspricht dem Observer-Pattern, wie es in Abschnitt 10.3.9 erläutert wurde.

Bei den Swing-Dialogelementen wird eine vereinfachte Variante von MVC verwendet, die auch als Model-Delegate-Prinzip bezeichnet wird. Hierbei wird die Funktionalität von View und Controller in einem UI Delegate zusammengefaßt. Dadurch wird einerseits die Komplexität reduziert (oft ist der Controller so einfach strukturiert, daß es sich nicht lohnt, ihn separat zu betrachten) und andererseits die in der Praxis mitunter unhandliche Trennung zwischen View und Controller aufgehoben. Es kann allerdings sein, daß ein Dialogelement mehr als ein Model besitzt. So haben beispielsweise Listen und Tabellen neben ihrem eigentlichen Datenmodell ein weiteres, das nur für die Selektion von Datenelementen zuständig ist.

Aber...

Natürlich wäre es zu schön, wenn die geschilderten Eigenschaften frei von "Nebenwirkungen" wären. Dem ist (natürlich) nicht so. Neben den vielen Vorteilen bringt die Verwendung von Swing auch Probleme mit sich:

• Swing-Anwendungen sind ressourcenhungrig. Daß alle Komponenten selbst gezeichnet werden müssen, erfordert viel CPU-Leistung und eine Menge Hauptspeicher. Die Attribute "speicherfressend" und "langsam", die Java-Programmen oft pauschal zugeschrieben werden, resultieren zu einem nicht unerheblichen Teil aus der Verwendung der Swing-Bibliotheken.
• Zweitens stecken noch eine Menge kleinerer und größerer Fehler in den Swing-Bibliotheken. Eines der häßlichsten Probleme im JDK 1.3 ist die Eigenschaft von Swing-Fensterelementen, belegte Ressourcen nicht vollständig freizugeben und so bei wiederholtem Öffnen und Schließen nach und nach den gesamten Hauptspeicher aufzubrauchen. Mit 1.3 scheint dieses Problem nicht mehr oder nur noch abgeschwächt aufzutreten.
• Für Applet-Programmierer ist vor allem unschön, daß es nach wie vor keine Browser mit eingebauter Swing-Unterstützung gibt. Sie müssen daher entweder das Java-Plugin verwenden (und dem Anwender damit einen zusätzlichen Download- und Installationsschritt zumuten) oder sind nach wie vor auf die Verwendung des AWT beschränkt.

Glücklicherweise ist Licht am Horizont zu sehen! Die steigenden Rechnerleistungen kompensieren die Hardwareanforderungen der Swing-Programme; aktuelle Einsteiger-PCs haben genügend Leistung und Hauptspeicher, um Swing-Anwendungen hinreichend performant auszuführen. Mit dem JDK 1.3 hat SUN zudem einen weiteren Schritt in die richtige Richtung gemacht. Die Startzeiten der Anwendungen wurden verkürzt, der Speicherhunger eingedämmt, und viele der früheren Bugs wurden behoben.

35.1.3 Wie geht es weiter?

Wir wollen uns in diesem und den nächsten Kapiteln mit den grundlegenden Eigenschaften von Swing beschäftigen. Der Schwerpunkt der Darstellung liegt dabei auf der Beschreibung der einzelnen Komponenten - mit dem Anspruch, zumindest ihre jeweils wichtigsten Merkmale zu behandeln. Die meisten Themen können dabei allerdings nur angerissen werden, denn eine einigermaßen vollständige Beschreibung von Swing benötigt ein eigenes Buch.

Meist werden wir daher lediglich die wichtigsten Methoden einer Klasse vorstellen. Speziellere Eigenschaften müssen wir außer acht lassen. Auch auf die übrigen Komponenten der Java Foundation Classes, die 2D- und Accessibility-APIs, das Input Method Framework und das Drag-and-Drop API werden wir allenfalls in Ansätzen eingehen.

Es empfiehlt sich daher, nach den ersten Experimenten weitere Literatur zu Rate zu ziehen. Swing-Bücher sind mittlerweile in großer Zahl erhältlich. Auch das frei erhältliche Java-Tutorial von SUN (siehe Abschnitt 3.2.2) enthält einen Abschnitt "Creating a GUI with JFC/Swing", der das Erstellen von Swing-Applikationen ausführlich beschreibt. Am wichtigsten ist jedoch die API-Dokumentation. Sie ist das Hilfsmittel zum Erforschen der verborgenen Möglichkeiten einzelner Swing-Bestandteile.

Bevor wir in den nächsten Kapiteln in die Beschreibung der Komponenten einsteigen, wollen wir in den beiden letzten Abschnitten dieses Kapitels noch etwas für die Ungeduldigen tun. Zunächst zeigen wir ein einfaches Beispiel, an dem die Grundstruktur eines Swing-Programms erläutert wird. Darin demonstrieren wir auch, wie das Look-and-Feel des Programms zur Laufzeit umgeschaltet werden kann. Anschließend geben wir einige Tips zur Umstellung von AWT-Anwendungen auf Swing und zeigen wichtige Gemeinsamkeiten und Unterschiede zwischen den beiden Welten auf.