Swing (Java)
# Swing (Java)

Swing ist ein GUI-Toolkit für die Programmiersprache Java von Sun Microsystems. Seit Java-Version 1.2 (1998) ist es Bestandteil der Java-Runtime. Swing gehört zu den Java Foundation Classes (JFC), die eine Sammlung von Bibliotheken zur Programmierung von grafischen Benutzerschnittstellen bereitstellen. Zu diesen Bibliotheken gehören Java 2D, die Java Accessibility API (JAAPI), das Drag-and-Drop-API und das Abstract Window Toolkit (AWT). Swing baut auf dem älteren AWT auf und ist mit den anderen APIs verwoben.
Hauptkonkurrent von Swing ist das für Eclipse entwickelte SWT. Der designierte Nachfolger von Swing ist das Framework JavaFX, das seit März 2014 im Lieferumfang des Oracle JDK enthalten ist, das aber bisher nicht durch den Java Community Process als offizieller Java-Standard spezifiziert wurde.

## Merkmale
### Aufbau

Swing ist modular und objektorientiert aufgebaut, so dass es sich gerade für die Entwicklung komplexer Anwendungen gut eignet. Durch die Plattformunabhängigkeit entfällt ebenfalls viel Entwicklungs- und Testarbeit.

### Pluggable Look-and-Feel

Das Erscheinungsbild (Look, siehe Skin) und das Verhalten (Feel) von Swing-Komponenten kann mittels sogenannter Look-and-Feels angepasst werden. Auf allen Plattformen stehen sowohl das Motif-Look-and-Feel als auch das Metal-Look-and-Feel (ab Java 5 das Ocean-Look-and-Feel) zur Verfügung, auf Linux Gtk, Mac und Windows zusätzlich ein dem systemüblichen angepasstes eigenes Look and Feel. Es existieren eine Reihe unabhängig entwickelter Erscheinungsbilder, wovon die meisten auf Metal basieren. Seit Java 1.5 ist das Synth-Look-and-Feel hinzugekommen, dessen aus Bildern zusammengesetztes Erscheinungsbild in einer XML-Datei beschrieben wird, sodass kein Java-Code geschrieben werden muss. Mit Java 1.6, Update 10 wurde das vollständig vektorbasierte Nimbus-Look-and-Feel eingeführt.

### Leichtgewichtige Komponenten

Swing-Komponenten werden direkt von Java gerendert und sind nicht von nativen Betriebssystemkomponenten abhängig. Dadurch funktionieren alle Swing-Komponenten auf allen Plattformen gleich, unabhängig davon, ob die entsprechende Plattform eine Komponente zur Verfügung stellt oder nicht. Der Nachteil ist, dass eine Swing-Anwendung nicht wie eine für das Betriebssystem entwickelte Anwendung aussieht. Das kann aber durch eine Auswahl an entsprechenden Pluggable Look-and-Feels kompensiert werden. Diese Eigenschaft wird mit dem englischen Wort Lightweight UI beschrieben (lightweight = all-Java language).

### Vergleich

Im Vergleich zu AWT hat man mit Swing folgende zusätzliche Komponenten, die zur Oberflächenerzeugung genutzt werden können:
* Keyboard Accelerators, also Tastenkombinationen zur Steuerung von Komponenten
* Drag and Drop
* Setzen des Look and Feel
* Tooltips
* automatisches Double Buffering
* neue Layout-Manager/Panels
* Anwendungen mit Multiple Document Interface
* zusätzliche Komponenten, um Tabellen und Baumstrukturen darzustellen

### Multithreading

Swing ist nicht thread-sicher, es kann also zu unerwarteten Wechselwirkungen zwischen verschiedenen Threads kommen, wenn nicht sorgfältig programmiert wird. Stattdessen sind die Swing-Komponenten so implementiert, dass ihre Methoden stets in einem sogenannten Event Dispatch Thread des AWT ausgeführt werden müssen, der die gesamte Ereignisverarbeitung grafisch-interaktiver Java-Anwendungen durchführt. Um dies zu vereinfachen, stellt die Hilfsklasse SwingUtilities zwei Methoden bereit, die aus anderen Threads heraus aufgerufen werden können und ein ausführbares Objekt vom Typ Runnable als Parameter nehmen.
* invokeLater reiht das ausführbare Objekt in die Ereigniswarteschlange von AWT ein und kehrt noch vor dessen Ausführung in den aufrufenden Code zurück. Der aufrufende Thread wird also nicht blockiert.
* invokeAndWait reiht das ausführbare Objekt in die Ereigniswarteschlange von AWT ein und wartet, bis es abgearbeitet wurde. Der aufrufende Thread wird also blockiert.
Verstöße gegen diese Konventionen werden dem Programmierer nicht gemeldet, so dass damit verbundene Schwierigkeiten lange unentdeckt bleiben bzw. gar nicht behoben werden. UI-Frameworks wie SWT oder auch .NET WinForms handhaben dies anders und quittieren fehlerhafte Aufrufe sofort.
Außerhalb des JRE stellte Sun eine SwingWorker genannte Basisklasse zur Verfügung, die zwei zu überladende Methoden anbietet: Eine, die in einem eigenen Thread aufgerufen wird und eine längerdauernde Operation ausführen kann und eine weitere, die nach dem Ende dieser Operation im Event Dispatch Thread ausgeführt wird und Swing-Komponenten manipulieren darf. Des Weiteren existiert ein Mechanismus, der es erlaubt, Zwischenschritte (z. B. in einer Fortschritts-Anzeige) zu visualisieren. Seit Java 1.6 ist sie als javax.swing.SwingWorker im JRE enthalten.

## Geschichte

Swing wurde erstmals mit dem JDK 1.1.5 Ende 1997 als externe Bibliothek ausgeliefert und ist seit JDK 1.2 („Java 2“) Ende 1998 fester Bestandteil der Java-Laufzeitumgebung. Swing hatte sehr bald den Ruf, eine schlechte Performance aufzuweisen und für „ernsthafte“ Anwendungen ungeeignet zu sein. Der Standard-Stil (Look&Feel) von Swing-Fenstern fand ebenfalls nicht besonders viele Freunde.
Sun legte daraufhin großes Augenmerk auf die Verbesserung des Aussehens der mitgelieferten Look and Feels, sowie der Performance von Swing. Mittlerweile hat sich die Performance durch verbesserte Hardwareunterstützung der Beschleunigungsfunktionen von Grafikkarten, sowie über Performance-Verbesserungen in den Klassenbibliotheken selbst und bei der Java Runtime deutlich verbessert. Spätestens seit Java Version 1.4 2002 weist Swing keine merkbaren Performanceunterschiede zu nativen GUIs auf. Auch Performancevergleiche zwischen Swing und SWT zeigen keine Performanceunterschiede auf.

## Beispiel

Als Beispiel für eine Swing-Anwendung wird hier das Hallo-Welt-Programm angegeben:
Teile dieses Quellcodes werden von unterschiedlichen Threads ausgeführt. Der Thread, der die Methode main ausführt, ist für gewöhnlich nicht der Event-Dispatch-Thread (EDT). Swingkomponenten sollten jedoch generell nur vom EDT erzeugt und verändert werden (falls in der Dokumentation nicht ausdrücklich anderes steht). Daher wird der Quellcode für die GUI in ein eigenes Runnable-Objekt verpackt. Der Thread, der die Methode main ausführt, erzeugt also nur das Runnable-Objekt und weist Swing an, diesen Quellcode später im EDT auszuführen.

## Erweiterungen

Swing lässt sich an verschiedenen Stellen mittels des in Swing eingebauten Plug-In-Konzeptes erweitern. Typische Erweiterungen betreffen Look&Feels, Layoutmanager und weitere Komponenten.
Das SUN-Open-Source-Projekt SwingLabs bietet eine Reihe von Erweiterungen für Swing und dient als Testumgebung für zukünftige Erweiterungen von Swing. Unter anderem wurden in SwingLabs die in Java 6 eingeführten Klassen GroupLayout, SystemTray und Desktop gehostet. Weitere Erweiterungen werden von der java.net Java Desktop Community im Java Desktop Swing Depot gesammelt. JGoodies von Karsten Lentzsch bietet ebenso eine Reihe an Swing-Erweiterungen, wie beispielsweise das FormLayout.
Das Projekt Spring Richclient bietet eine Integration von Swing in das Spring Framework. Es wird allerdings seit Mitte 2009 nicht mehr weiterentwickelt.

## Editoren

Es gibt eine Reihe meist kostenpflichtiger WYSIWYG GUI Design Tools für Swing. Die folgenden sind die bekanntesten:
* JFormDesigner – Kommerzieller Editor, sowohl eigenständig als auch als Eclipse-, IntelliJ-IDEA- und JBuilder-Plugin
* Jigloo – Kommerzielles Eclipse-Plugin für Swing- und SWT-GUIs, kostenlos für nicht kommerzielle Zwecke
* Eclipse WindowBuilder – offizielles Eclipse-Plugin für Swing-, SWT-, AWT- und GWT-Oberflächen
* Matisse4MyEclipse – Portierung von Matisse, dem GUI-Builder der NetBeans IDE, für Eclipse und Swing, läuft nur unter MyEclipse
* Visual Editor – Open-Source-Eclipse-Plugin für Swing- und SWT-GUIs (zugehöriges Entwicklungsprojekt ist seit April 2012 nicht mehr aktiv)