Skip to Content

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)

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 Browsers 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)

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.

/sites/default/files

Duke auf Schaukel

Java 1.2: JFC/Swing Standard GUI

  • Jahr 1998

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 (Quellen der Demoanwendung)

"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.

Abwägung
  Vorteile Nachteile
Heavyweight
  • Schnell, automatische Grafikbeschleunigung
  • Perfekte Abstimmung mit anderen grafischen Elementen des OS
  • Look & Feel des Betriebssystems
  • Plattformabhängig
    • Ereignisse
    • Komponenten
    • Look & Feel
Lightweight
  •  Plattformunabhängig
    • einheitliches Modell für Ereignisse
    • Look & Feel frei wählbar
    • Es können Ereignisse und Komponenten modelliert werden die eine Plattform nicht bietet
  • Plattform kennt Ereignisse und Komponenten nicht
  • Grafikbeschleunigung kann fehlen (nicht mehr relevant in den aktuellen Java Versionen)
  • Komplexere Interaktion mit grafischen Komponenten anderer Programme (Zwischenablagen, Verdecken von Bereichen etc.)

 

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.



book | by Dr. Radut