Entwicklungsgeschichte der grafischen Benutzerschnittstellen in Java (JRE)
Entwicklungsgeschichte der grafischen Benutzerschnittstellen in Java (JRE)Swing ist das Ergebnis einer Evolution der grafischen Benutzerschnittstellen die seit 1996 immer weiterentwickelt wurden. Der geschichtliche Überblick ist hilfreich beim Verstehen der recht komplexen Paketstrukturen von Swing und AWT.
Java 1.0: Another Windowing Toolkit (AWT)
- Jahr 1996
- Paket: java.awt.*
Die ursprüngliche Grafikbibliothek AWT sollte die folgenden Anforderungen erfüllen
- einfach zu verstehen und zu Programmieren ("Volks GUI")
- weniger komplex als das damals populäre X11, Motif von Unix-Workstations
- unabhängig von Windows (Rechte, Lizensen!)
- Kleine Teilmenge der wichtigsten GUI Elemente
- geplanter Einsatz Browser-Applets und TV-Settop Boxen (Auf Neudeutsch "Kabeltuner")
- Internet Browser zu mehr Interaktion und mehr Intelligenz zu verhelfen
- leicht auf unterschiedlichen Betriebssytemen zu implementieren
AWT hat daher die folgenden Eigenschaften
- nur wenige GUI Komponenten
- HeavyWeight Implementierung (direkte Abbildung auf Betriebssystemkomponenten)
- Threadsicher
- keine Model-View-Controller Architektur
Java 1.1: AWT + Java Foundation Classes (JFC)
- Jahr 1997
- Paket: javax.swing.*
Das AWT musste um eine objektorientierte Ereignissteuerung erweitert werden da das Implementieren von GUIs mit vielen Komponenten sehr unübersichtich war
Gleichzeitig wurde ein vollkommenes Neudesign mit einem optionalen Package (javax Pakete) mit dem Projektnamen Swing (engl. Schaukel) vorgestellt. Der offizielle Name war "Java Foundation Classes".
Da JFC zum Zugriff auf die Betriebssytemkomponenten AWT benutzen muss, ist es von AWT abhängig. JFC ist eine "light weight" Implementierung und daher stärker vom gegebenen Betriebssytemen entkoppelt.
Java 1.2: JFC/Swing Standard GUI
JFC (Swing) muss nicht mehr separat geladen werden und ist Bestandteil des Standard JREs. Es verdrängt AWT mehr und mehr. Seine wichtigsten Eigenschaften sind
Swing wurde seit JRE 1.2 kontinuierlich weiterentwickelt und erhielt in jeder neuen JRE Version zusätzliche Eigenschaften. Die Demoanwendung SwingSet2 ist eine gute Referenzanwendung in der sehr viele Komponenten verwendet werden. |
"Lightweight" versus "Heavyweight" Implementierungen
Man spricht von Heavyweight Komponenten wenn zu ihrer Implementierung die vom Betriebssytem zu Verfügung gestellten Komponenten verwendet werden.
In einer Heavyweight Implementierung wird z.Bsp. zur Anzeige einer Menüauswahliste direkt die Menüauswahlliste des Betriebssytem verwendet.
Man spricht von einer Lightweight Implementierung wenn eine Grafikbibliothek vom Betriebsystem nur einen Pixelbereich auf dem Bildschirm nutzt und dann die Komponenten selbst zeichnet (rendered). Bei einer Lightweigtimplemenierung muss die Anwendung zum Beispiel eine Menüauswahlliste selbst auf dem Bildschirm zeichnen und selbst darauf achten, welche Bereiche des Fenster überschrieben werden.
Vorteile | Nachteile | |
---|---|---|
Heavyweight |
|
|
Lightweight |
|
|
Anmerkung: Die historischen (vor 2005) Probleme von Swing sind in den aktuellen Javaversion nicht mehr vorhanden. Moderne Garbage-Kollektoren blockieren die Benutzerschnittstellen nicht mehr sichtbar. Die aktuelle 2D Bibliothek von Java zeichnet in der Regel ausreichend schnell und benutzt auf den gängigen Plattformen (Windows, Mac, Linux) die Betriebssystemoptimierungen für Fonts, 2D- und 3D-Operationen. JavaFX stellt auch die nötigen hardwareunterstützten Operationen für Bildtransformationen und Filme zur Verfügung.
- 6146 views