18    Einführung in grafische Oberflächen 

»Wenn die Reklame keinen Erfolg hat, muss man die Ware ändern.«

– Edgar Faure (1908–1988)

 

18.1    GUI-Frameworks 

Benutzeroberfläche oder User Interface, kurz UI, nennen wir die Schnittstelle zwischen Mensch und Anwendung.

 

18.1.1    Kommandozeile 

Am Anfang der Mensch-Maschine-Interaktion stand die Kommandozeile (engl. command line interface, kurz CLI). Java bietet hierfür nur rudimentäre Unterstützung:

• Die Ausgaben auf der Kommandozeile bzw. Shell laufen über System.out und System.err, die Eingaben über System.in.

• Einige Shells bieten Positionierungen eines Cursors oder Farben, doch da dies nicht plattformunabhängig ist, bietet Java keine Unterstützung an. Das kann durch quelloffene Erweiterungen jedoch ermöglicht werden.

• Die an das Java-Programm übergebenen Kommandozeilenargumente landen bei der Methode main(String[] args) in der Parametervariablen args.

• Rückgaben vom Java-Programm an die Shell sind über einen Methodenaufruf System.exit(int) möglich.

• Es fehlen das komfortable Parsen der Programmargumente und das Auswerten der Optionen. Quelloffene Bibliotheken schaffen hier Abhilfe.

 

18.1.2    Grafische Benutzeroberfläche 

Das Aufkommen von grafischen Benutzeroberflächen oder Graphical User Interfaces, kurz GUI, ab den 1970er-Jahren verdrängte immer mehr die Kommandozeile, und Benutzer konnten die Anwendungen mit Fenstern, Symbolen und Interaktionskomponenten bedienen.

Die Java-Plattform hat sich zum Ziel gesetzt, plattformunabhängige Softwareentwicklung zu unterstützen, und dazu gehört auch eine Bibliothek zur Gestaltung grafischer Oberflächen. Eine Bibliothek sollte dabei im Wesentlichen die folgenden Bereiche abdecken:

• Sie beherrscht das Zeichnen grafischer Grundelemente wie Linien und Polygone, setzt performant Grafiken, ermöglicht das Setzen von Farben und bietet eine ordentliche Darstellung von Text.

• Sie bietet grafische Komponenten (GUI-Komponenten), auch Steuerelemente oder Widgets genannt, wie zum Beispiel Fenster, Schaltflächen, Textfelder und Menüs.

• Sie definiert ein Modell zur Behandlung von Ereignissen, wie etwa Mausbewegungen.

Zur GUI-Entwicklung in Java gibt es Frameworks, also Bibliotheken, mit denen sich grafische Oberflächen programmieren lassen. Drei Frameworks bringt Java gleich mit.

 

18.1.3    Abstract Window Toolkit (AWT) 

Als Sun 1995 Java veröffentlichte, gehörte ein Framework zur Gestaltung (einfacher) grafischer Oberflächen schon gleich mit zur Standard-API: das Abstract Window Toolkit (AWT). Es bietet Methoden für Primitivoperationen zum Zeichnen, zur Ereignisbehandlung und einen einfachen Satz von GUI-Komponenten, wie Beschriftungen, Schaltflächen und Textfelder. Das AWT ist eine portable GUI-Bibliothek, die auf nativen Komponenten des Betriebssystems basiert und folglich auch hervorragende Performance und im Grunde gute Portabilität bietet.

 

18.1.4    Java Foundation Classes und Swing 

Das AWT bietet nur lächerliche acht Komponenten,[ 255 ](Button, Checkbox, Choice, Label, List, Scrollbar, TextArea, TextField – die Container und eine generische Zeichenfläche Canvas einmal außen vor gelassen ) und anspruchsvolle Oberflächen sind damit nur mit viel Handarbeit möglich. Sun entschloss sich daher schon früh, das AWT zu erneuern, und so flossen neue Komponenten – die sogenannten Swing-Komponenten – sowie eine neue Java 2D-API und weitere Dienste fest in Java 1.2 ein. (Zur Erinnerung: Das war Ende 1998.) Die Gesamtheit von AWT und Swing bilden die Java Foundation Classes, kurz JFC. Sie sind bis heute Teil der Java SE und seit Java 9 ein eigenes Modul.

 

18.1.5    JavaFX 

Seit etwa 20 Jahren realisieren Swing bzw. die Java Foundation Classes grafische Anwendungen unter Java. Zwar sind die Java Foundation Classes mächtig, aber sie haben sich in den letzten Jahren nicht großartig weiterentwickelt. Insbesondere gibt es Lücken im Bereich ausgereifter Komponenten sowie bei der Medienunterstützung und Animation, etwas, was bei modernen grafischen Oberflächen heutzutage gefragt ist. Anstatt in die Weiterentwicklung der JFC zu investieren, hat sich Sun/Oracle für eine komplette Neuentwicklung der GUI-Ebene entschieden, die nichts mehr mit Swing/AWT gemeinsam hat – herausgekommen ist JavaFX.

JavaFX ist eine Komplettlösung mit einer API für:

• GUI-Komponenten

• HTML/CSS/JavaScript mit eingebettetem Webbrowser

• Animationen

• Video

• Audio

• 2D und 3D

Da JavaFX komplett alle APIs für moderne Oberflächen anbietet und auch nicht von AWT/Swing abhängig ist, bildet JavaFX einen kompletten Media-Stack. Die Betonung liegt auf »Media«, denn die Java Foundation Classes können keine Videos einbinden oder abspielen. Anders als AWT ist die JavaFX-Implementierung auf der Höhe der Zeit und greift direkt auf alle 2D- und 3D-Fähigkeiten moderner Grafikkarten zurück. So kann mit JavaFX alles das programmiert werden, was bisher eher mit Flash gemacht wurde, allerdings fehlen noch die tollen Entwicklertools. Es gibt Plugins für Adobe Photoshop und Illustrator, mit denen Grafiken und Pfade exportiert werden können, aber eben keine ganzen Animationen, die etwa mit Adobe Flash erzeugt wurden.

Die Geschichte von JavaFX: JavaFX 1, JavaFX 2, JavaFX 8, OpenJFX 11

Ursprünglich wollte Sun/Oracle JavaFX als Flash-Ersatz im Internet positionieren, doch dafür ist die Kombination HTML5 + CSS3 + JavaScript zu attraktiv. JavaFX ist in erster Linie eine großartige GUI-Bibliothek für klassische Client-Anwendungen, die langsam auch auf mobile Endgeräte vorrückt. So nahm die Entwicklung auch unterschiedliche Richtungen.

JavaFX ist schon sehr lange in Entwicklung, und viele interne Swing-Entwickler wurden bei Sun/Oracle auf das Projekt angesetzt. Umgekehrt passierte bei den Java Foundation Classes nicht mehr viel, Bugfixes kommen aber immer noch brav. Im Jahr 2007 wurde JavaFX auf der JavaOne-Konferenz vorgestellt, Ende 2008 erschien das Release JavaFX 1.0 zusammen mit der Programmiersprache JavaFX Script. Die besondere Sprache machte es möglich, auf einfache Weise hierarchische Objektgraphen aufzubauen, und bot eine nette Syntax für Object-Binding, sodass Zustände synchronisiert werden konnten.

Im Oktober 2011 erschien JavaFX 2.0 mit vielen Neuerungen und auch Änderungen. So wurde JavaFX Script entfernt, denn Oracle wollte keine weitere Programmiersprache aufbauen, sondern eine pure Java-API, die Entwickler dann von unterschiedlichen existierenden Skriptsprachen aus ansprechen können. Das war sicherlich eine gute Entscheidung, denn unter JavaScript und Groovy sieht das sehr schlank aus, fast wie mit JavaFX Script. Mit dem Update auf JavaFX 2.0 änderte sich auch die API, sodass alter Code angefasst werden musste. Heute ist JavaFX 1 veraltet, genauso wie die Literatur dazu .

JavaFX entwickelte sich immer mehr zur Alternative zu Swing/AWT, und so integrierte Oracle im August 2012 das Java FX 2.2 SDK und die Runtime in das JRE/JDK 7 Update 6. Der Schritt war ungewöhnlich, denn so große Ergänzungen waren bisher als Update im JRE/JDK noch nie gemacht worden. Neben der Integration bewegte sich auch das ehemals geschlossene JavaFX in Richtung Open Source und mündete in der Implementierung OpenJFX. Mit dem OpenJDK und OpenJFX lässt sich ein komplett freies Java-System mit GUI-Stack unter der GPL bauen, was strikte Linux-Distributionen freuen wird. Die Offenheit führte schon zu sehr spannenden Experimenten, etwa einer Java-Version für iOS.

Mit Java 8 zog auch JavaFX 8 ein, der nächste Sprung mit 3D-Unterstützung. In Java 11 wiederum wurde JavaFX entfernt, und die Entwicklung findet in OpenJFX statt – das wird als Modul eingebunden und ist eine externe Bibliothek wie jede andere auch. OpenJFX ist also eine Implementierung der JavaFX-Technologie.

 

18.1.6    SWT (Standard Widget Toolkit) * 

Es gibt Anwendungsfälle, in denen weder AWT noch Swing noch JavaFX passen. Swing ist zwar sehr mächtig, doch kostet es auch einige Ressourcen. AWT ist schlank und recht schnell, bietet aber wenige Komponenten. Das AWT ist bei Geräten mit wenig Speicher, etwa Handheld-Geräten, noch eine interessante Variante, aber alles sieht so aus, als ob die Entwicklung bei OpenJFX weitergeht.

Im Jahr 1998 begann IBM mit der Entwicklung des Nachfolgers von VisualAge for Java (das in Smalltalk geschrieben war). Für die neue Entwicklungsumgebung – aus der später Eclipse wurde – benötigte das Entwicklerteam Oberflächenelemente. Swing war weit davon entfernt, zügig, speichereffizient und korrekt zu sein, und Sun führte schon damals die AWT-Entwicklung nicht erkennbar weiter. So entschied IBM, mit dem SWT (Standard Widget Toolkit) eine Alternative zum AWT zu entwickeln, die Möglichkeiten eines nativen grafischen Systems nutzen kann. Dazu zählen neben Komponenten wie Schaltflächen und Tabellen auch integrierte Fähigkeiten wie Drag & Drop, Zwischenablage, Drucken und ActiveX-Integration (unter Windows). Dabei nutzt SWT keinen Anteil von AWT, nicht einmal die grafischen Primitivoperationen oder Java 2D. Wegen dieser engen Kopplung an das System müssen die SWT-Applikationen mit einer dynamischen Bibliothek (DLL unter Windows) ausgeliefert werden. Eine Umsetzung gibt es heute außer für Windows (auch Windows CE) und macOS etwa auf diversen Motif-Plattformen, GTK (kein Qt) und QNX/Photon. (Wer nur unter GNOME und GTK+ programmiert, der sollte einen Blick auf Java-GNOME unter http://java-gnome.sourceforge.net werfen.)

Ursprünglich war das SWT (http://www.eclipse.org/swt) ausschließlich für die neue Entwicklungsumgebung gedacht. Mittlerweile erfreut sich die Swing-Alternative aber größerer Beliebtheit und ist inzwischen von der Entwicklungsumgebung losgelöst. Insbesondere für mobile Endgeräte (Windows CE) ist das SWT sehr performant, da die Bibliothek auf einem kleinen nativen Kern aufbaut und recht leichtgewichtig ist. Die Eclipse Rich Client Platform (RCP) ist ein großes Framework für komplexe grafische Oberflächen auf der Basis von SWT, das Aufgaben wie Konfigurationen für Benutzer oder Verteilung und Aktualisierung von Haus aus realisiert.

Das immer wieder vorgebrachte Argument, dass mit SWT die Java-Oberflächen genauso aussehen wie native Oberflächen der jeweiligen Plattform, ist fragwürdig. SWT-Oberflächen sehen anders aus, etwa bei den Reitern oder Menüs, und Swing kommt dem nativen Aussehen – insbesondere ab Java Version 6 unter Windows – eigentlich näher. Dem Anwender ist das ziemlich egal. Selbst in konservativeren Bereichen wie Office-Software haben sich Anwender daran gewöhnt, dass Microsoft in jeder Produktversion die Optik anpasst. Microsoft Office 2007 sieht völlig anders aus als Office 2003, dieses sieht wieder anders aus als Office 2016, und der Windows Media Player folgt auch nicht der Designsprache. Die Avantgarde der Anwender passte schon immer die Oberflächen an, und heute unterstützen bereits viele Anwendungen das Skinning.