Java III (Swing Package)

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

Einführung
Pakete,Basisklassen
Fensterklassen in Swing
JFrame
JWindow
Weitere Swing Container
Tooltips
Bildschirmdarstellung
Debug, Grafik
Doppeltepufferung
Dialogelemente I
Standarddialogelemente und Ihre Ereignisverarbeitung
Dialogelemente II
JSlider
JProgressBar
JScrollPane
JSplitPane
JTabbedPane
JTree
Erzeugen eines Baumes
Selektieren von Knoten
Abfragen und ändern von Knoten
Verändern der Baumstruktur
JTable
Implementierung und Konfiguration von Tabellen
Selektieren von Tabellen
Tabellen, Spaltenmodell
Rendering
Reaktion auf Ereignisse

Projekt innerhalb des Moduls
Entwicklung einer Swing-Applikation mit Desktopmanagement

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.

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.
(Hanbuch der Java Programmierung - Guido Krüger s.777ff.)