Rheinwerk Computing < openbook >


 
Inhaltsverzeichnis
Materialien
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Arrays und ihre Anwendungen
5 Der Umgang mit Zeichenketten
6 Eigene Klassen schreiben
7 Objektorientierte Beziehungsfragen
8 Ausnahmen müssen sein
9 Geschachtelte Typen
10 Besondere Typen der Java SE
11 Generics<T>
12 Lambda-Ausdrücke und funktionale Programmierung
13 Architektur, Design und angewandte Objektorientierung
14 Java Platform Module System
15 Die Klassenbibliothek
16 Einführung in die nebenläufige Programmierung
17 Einführung in Datenstrukturen und Algorithmen
18 Einführung in grafische Oberflächen
19 Einführung in Dateien und Datenströme
20 Einführung ins Datenbankmanagement mit JDBC
21 Bits und Bytes, Mathematisches und Geld
22 Testen mit JUnit
23 Die Werkzeuge des JDK
A Java SE-Module und Paketübersicht
Stichwortverzeichnis


Download:

- Listings, ca. 2,7 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil18 Einführung in grafische Oberflächen
Pfeil18.1 GUI-Frameworks
Pfeil18.1.1 Kommandozeile
Pfeil18.1.2 Grafische Benutzeroberfläche
Pfeil18.1.3 Abstract Window Toolkit (AWT)
Pfeil18.1.4 Java Foundation Classes und Swing
Pfeil18.1.5 JavaFX
Pfeil18.1.6 SWT (Standard Widget Toolkit) *
Pfeil18.2 Deklarative und programmierte Oberflächen
Pfeil18.2.1 GUI-Beschreibungen in JavaFX
Pfeil18.2.2 Deklarative GUI-Beschreibungen für Swing?
Pfeil18.3 GUI-Builder
Pfeil18.3.1 GUI-Builder für JavaFX
Pfeil18.3.2 GUI-Builder für Swing
Pfeil18.4 Mit dem Eclipse WindowBuilder zur ersten Swing-Oberfläche
Pfeil18.4.1 WindowBuilder installieren
Pfeil18.4.2 Mit WindowBuilder eine GUI-Klasse hinzufügen
Pfeil18.4.3 Das Layoutprogramm starten
Pfeil18.4.4 Grafische Oberfläche aufbauen
Pfeil18.4.5 Swing-Komponenten-Klassen
Pfeil18.4.6 Funktionalität geben
Pfeil18.5 Grundlegendes zum Zeichnen
Pfeil18.5.1 Die paint(Graphics)-Methode für das AWT-Frame
Pfeil18.5.2 Die ereignisorientierte Programmierung ändert Fensterinhalte
Pfeil18.5.3 Zeichnen von Inhalten auf einen JFrame
Pfeil18.5.4 Auffordern zum Neuzeichnen mit repaint(…)
Pfeil18.5.5 Java 2D-API
Pfeil18.6 Zum Weiterlesen
 

Zum Seitenanfang

18    Einführung in grafische Oberflächen Zur vorigen ÜberschriftZur nächsten Überschrift

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

– Edgar Faure (1908–1988)

 

Zum Seitenanfang

18.1    GUI-Frameworks Zur vorigen ÜberschriftZur nächsten Überschrift

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

 

Zum Seitenanfang

18.1.1    Kommandozeile Zur vorigen ÜberschriftZur nächsten Überschrift

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.

 

Zum Seitenanfang

18.1.2    Grafische Benutzeroberfläche Zur vorigen ÜberschriftZur nächsten Überschrift

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.

 

Zum Seitenanfang

18.1.3    Abstract Window Toolkit (AWT) Zur vorigen ÜberschriftZur nächsten Überschrift

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.

 

Zum Seitenanfang

18.1.4    Java Foundation Classes und Swing Zur vorigen ÜberschriftZur nächsten Überschrift

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.

 

Zum Seitenanfang

18.1.5    JavaFX Zur vorigen ÜberschriftZur nächsten Überschrift

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.

 

Zum Seitenanfang

18.1.6    SWT (Standard Widget Toolkit) * Zur vorigen ÜberschriftZur nächsten Überschrift

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.

 


Ihre Meinung?

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java ist auch eine Insel Java ist auch eine Insel

Jetzt Buch bestellen


 Buchempfehlungen
Zum Rheinwerk-Shop: Captain CiaoCiao erobert Java

Captain CiaoCiao erobert Java




Zum Rheinwerk-Shop: Java SE 9 Standard-Bibliothek

Java SE 9 Standard-Bibliothek




Zum Rheinwerk-Shop: Algorithmen in Java

Algorithmen in Java




Zum Rheinwerk-Shop: Objektorientierte Programmierung

Objektorientierte Programmierung




 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2021

Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.

Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

[Rheinwerk Computing]



Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de



Cookie-Einstellungen ändern