Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Neues in Java 7
2 Threads und nebenläufige Programmierung
3 Datenstrukturen und Algorithmen
4 Raum und Zeit
5 Dateien, Verzeichnisse und Dateizugriffe
6 Datenströme
7 Die eXtensible Markup Language (XML)
8 Dateiformate
9 Grafische Oberflächen mit Swing
10 Grafikprogrammierung
11 Netzwerkprogrammierung
12 Verteilte Programmierung mit RMI
13 RESTful und SOAP Web-Services
14 JavaServer Pages und Servlets
15 Applets
16 Datenbankmanagement mit JDBC
17 Technologien für die Infrastruktur
18 Reflection und Annotationen
19 Dynamische Übersetzung und Skriptsprachen
20 Logging und Monitoring
21 Java Native Interface (JNI)
22 Sicherheitskonzepte
23 Dienstprogramme für die Java-Umgebung
Stichwort

Buch bestellen
Ihre Meinung?

Spacer
Java 7 - Mehr als eine Insel von Christian Ullenboom
Das Handbuch zu den Java SE-Bibliotheken
Buch: Java 7 - Mehr als eine Insel

Java 7 - Mehr als eine Insel
Rheinwerk Computing
1433 S., 2012, geb.
49,90 Euro, ISBN 978-3-8362-1507-7
Pfeil 9 Grafische Oberflächen mit Swing
Pfeil 9.1 Fenster zur Welt
Pfeil 9.1.1 Swing-Fenster mit javax.swing.JFrame darstellen
Pfeil 9.1.2 Fenster schließbar machen – setDefaultCloseOperation()
Pfeil 9.1.3 Sichtbarkeit des Fensters
Pfeil 9.1.4 Größe und Position des Fensters verändern
Pfeil 9.1.5 Fenster- und Dialog-Dekoration, Transparenz *
Pfeil 9.1.6 Die Klasse Toolkit *
Pfeil 9.1.7 Dynamisches Layout während einer Größenänderung *
Pfeil 9.1.8 Zum Vergleich: AWT-Fenster darstellen *
Pfeil 9.2 Beschriftungen (JLabel)
Pfeil 9.2.1 Mehrzeiliger Text, HTML in der Darstellung
Pfeil 9.3 Icon und ImageIcon für Bilder auf Swing-Komponenten
Pfeil 9.3.1 Die Klasse ImageIcon
Pfeil 9.3.2 Die Schnittstelle Icon und eigene Icons zeichnen *
Pfeil 9.4 Es tut sich was – Ereignisse beim AWT
Pfeil 9.4.1 Die Ereignisquellen und Horcher (Listener) von Swing
Pfeil 9.4.2 Listener implementieren
Pfeil 9.4.3 Listener bei dem Ereignisauslöser anmelden/abmelden
Pfeil 9.4.4 Adapterklassen nutzen
Pfeil 9.4.5 Innere Mitgliedsklassen und innere anonyme Klassen
Pfeil 9.4.6 Aufrufen der Listener im AWT-Event-Thread
Pfeil 9.4.7 Ereignisse, etwas genauer betrachtet *
Pfeil 9.5 Schaltflächen
Pfeil 9.5.1 Normale Schaltflächen (JButton)
Pfeil 9.5.2 Der aufmerksame ActionListener
Pfeil 9.5.3 Schaltflächen-Ereignisse vom Typ ActionEvent
Pfeil 9.5.4 Basisklasse AbstractButton
Pfeil 9.5.5 Wechselknopf (JToggleButton)
Pfeil 9.6 Textkomponenten
Pfeil 9.6.1 Text in einer Eingabezeile
Pfeil 9.6.2 Die Oberklasse der Text-Komponenten (JTextComponent)
Pfeil 9.6.3 Geschützte Eingaben (JPasswordField)
Pfeil 9.6.4 Validierende Eingabefelder (JFormattedTextField)
Pfeil 9.6.5 Einfache mehrzeilige Textfelder (JTextArea)
Pfeil 9.6.6 Editor-Klasse (JEditorPane) *
Pfeil 9.7 Swing Action *
Pfeil 9.8 JComponent und Component als Basis aller Komponenten
Pfeil 9.8.1 Hinzufügen von Komponenten
Pfeil 9.8.2 Tooltips (Kurzhinweise)
Pfeil 9.8.3 Rahmen (Border) *
Pfeil 9.8.4 Fokus und Navigation *
Pfeil 9.8.5 Ereignisse jeder Komponente *
Pfeil 9.8.6 Die Größe und Position einer Komponente *
Pfeil 9.8.7 Komponenten-Ereignisse *
Pfeil 9.8.8 UI-Delegate – der wahre Zeichner *
Pfeil 9.8.9 Undurchsichtige (opake) Komponente *
Pfeil 9.8.10 Properties und Listener für Änderungen *
Pfeil 9.9 Container
Pfeil 9.9.1 Standardcontainer (JPanel)
Pfeil 9.9.2 Bereich mit automatischen Rollbalken (JScrollPane)
Pfeil 9.9.3 Reiter (JTabbedPane)
Pfeil 9.9.4 Teilungskomponente (JSplitPane)
Pfeil 9.10 Alles Auslegungssache: die Layoutmanager
Pfeil 9.10.1 Übersicht über Layoutmanager
Pfeil 9.10.2 Zuweisen eines Layoutmanagers
Pfeil 9.10.3 Im Fluss mit FlowLayout
Pfeil 9.10.4 BoxLayout
Pfeil 9.10.5 Mit BorderLayout in alle Himmelsrichtungen
Pfeil 9.10.6 Rasteranordnung mit GridLayout
Pfeil 9.10.7 Der GridBagLayoutmanager *
Pfeil 9.10.8 Null-Layout *
Pfeil 9.10.9 Weitere Layoutmanager
Pfeil 9.11 Rollbalken und Schieberegler
Pfeil 9.11.1 Schieberegler (JSlider)
Pfeil 9.11.2 Rollbalken (JScrollBar) *
Pfeil 9.12 Kontrollfelder, Optionsfelder, Kontrollfeldgruppen
Pfeil 9.12.1 Kontrollfelder (JCheckBox)
Pfeil 9.12.2 ItemSelectable, ItemListener und das ItemEvent
Pfeil 9.12.3 Sich gegenseitig ausschließende Optionen (JRadioButton)
Pfeil 9.13 Fortschritte bei Operationen überwachen *
Pfeil 9.13.1 Fortschrittsbalken (JProgressBar)
Pfeil 9.13.2 Dialog mit Fortschrittsanzeige (ProgressMonitor)
Pfeil 9.14 Menüs und Symbolleisten
Pfeil 9.14.1 Die Menüleisten und die Einträge
Pfeil 9.14.2 Menüeinträge definieren
Pfeil 9.14.3 Einträge durch Action-Objekte beschreiben
Pfeil 9.14.4 Mit der Tastatur: Mnemonics und Shortcut
Pfeil 9.14.5 Der Tastatur-Shortcut (Accelerator)
Pfeil 9.14.6 Tastenkürzel (Mnemonics)
Pfeil 9.14.7 Symbolleisten alias Toolbars
Pfeil 9.14.8 Popup-Menüs
Pfeil 9.14.9 System-Tray nutzen *
Pfeil 9.15 Das Model-View-Controller-Konzept
Pfeil 9.16 Auswahlmenüs, Listen und Spinner
Pfeil 9.16.1 Listen (JList)
Pfeil 9.16.2 Auswahlmenü (JComboBox)
Pfeil 9.16.3 Drehfeld (JSpinner) *
Pfeil 9.16.4 Datumsauswahl *
Pfeil 9.17 Tabellen (JTable)
Pfeil 9.17.1 Ein eigenes Tabellen-Model
Pfeil 9.17.2 Basisklasse für eigene Modelle (AbstractTableModel)
Pfeil 9.17.3 Ein vorgefertigtes Standard-Modell (DefaultTableModel)
Pfeil 9.17.4 Ein eigener Renderer für Tabellen
Pfeil 9.17.5 Zell-Editoren
Pfeil 9.17.6 Größe und Umrandung der Zellen *
Pfeil 9.17.7 Spalteninformationen *
Pfeil 9.17.8 Tabellenkopf von Swing-Tabellen *
Pfeil 9.17.9 Selektionen einer Tabelle *
Pfeil 9.17.10 Automatisches Sortieren und Filtern mit RowSorter *
Pfeil 9.18 Bäume (JTree)
Pfeil 9.18.1 JTree und sein TreeModel und TreeNode
Pfeil 9.18.2 Selektionen bemerken
Pfeil 9.18.3 Das TreeModel von JTree *
Pfeil 9.19 JRootPane und JDesktopPane *
Pfeil 9.19.1 Wurzelkomponente der Top-Level-Komponenten (JRootPane)
Pfeil 9.19.2 JDesktopPane und die Kinder von JInternalFrame
Pfeil 9.19.3 JLayeredPane
Pfeil 9.20 Dialoge und Window-Objekte
Pfeil 9.20.1 JWindow und JDialog
Pfeil 9.20.2 Modal oder nicht-modal?
Pfeil 9.20.3 Standarddialoge mit JOptionPane
Pfeil 9.20.4 Der Dateiauswahldialog
Pfeil 9.20.5 Der Farbauswahldialog JColorChooser *
Pfeil 9.21 Flexibles Java-Look-and-Feel
Pfeil 9.21.1 Look and Feel global setzen
Pfeil 9.21.2 UIManager
Pfeil 9.21.3 Die Windows-Optik mit JGoodies Looks verbessern *
Pfeil 9.22 Swing-Komponenten neu erstellen oder verändern *
Pfeil 9.22.1 Überlagerungen mit dem Swing-Komponenten-Dekorator JLayer
Pfeil 9.23 Die Zwischenablage (Clipboard)
Pfeil 9.23.1 Clipboard-Objekte
Pfeil 9.23.2 Mit Transferable auf den Inhalt zugreifen
Pfeil 9.23.3 DataFlavor ist das Format der Daten in der Zwischenablage
Pfeil 9.23.4 Einfügungen in der Zwischenablage erkennen
Pfeil 9.23.5 Drag & Drop
Pfeil 9.24 Undo durchführen *
Pfeil 9.25 AWT, Swing und die Threads
Pfeil 9.25.1 Ereignisschlange (EventQueue) und AWT-Event-Thread
Pfeil 9.25.2 Swing ist nicht thread-sicher
Pfeil 9.25.3 invokeLater() und invokeAndWait()
Pfeil 9.25.4 SwingWorker
Pfeil 9.25.5 Eigene Ereignisse in die Queue setzen *
Pfeil 9.25.6 Auf alle Ereignisse hören *
Pfeil 9.26 Barrierefreiheit mit der Java Accessibility API
Pfeil 9.27 Zeitliches Ausführen mit dem javax.swing.Timer
Pfeil 9.28 Die Zusatzkomponentenbibliothek SwingX
Pfeil 9.28.1 Im Angebot: Erweiterte und neue Swing-Komponenten
Pfeil 9.28.2 Überblick über erweiterte Standard-Swing-Klassen
Pfeil 9.28.3 Neue Swing-Klassen
Pfeil 9.28.4 Weitere SwingX-Klassen
Pfeil 9.28.5 SwingX-Installation
Pfeil 9.29 Alternativen zu programmierten Oberflächen, AWT und Swing *
Pfeil 9.29.1 Deklarative Beschreibungen der Oberfläche: Swing JavaBuilder, Swixml
Pfeil 9.29.2 SWT (Standard Widget Toolkit)
Pfeil 9.30 Zum Weiterlesen

Rheinwerk Computing - Zum Seitenanfang

9.25 AWT, Swing und die ThreadsZur nächsten Überschrift

Swing nutzt für Zeichenoperationen und das Abarbeiten von Ereignis-Programmcode einen einen Thread. Die folgenden Abschnitte erklären, warum Swing einen eigenen Thread nutzt, und welche Konsequenzen das für den Entwickler hat.


Rheinwerk Computing - Zum Seitenanfang

9.25.1 Ereignisschlange (EventQueue) und AWT-Event-ThreadZur nächsten ÜberschriftZur vorigen Überschrift

Der Benutzer erzeugt bei seiner Arbeit mit der Oberfläche Ereignisse. Diese werden entweder von den Peer-Objekten oder von Klassen der Applikation erzeugt. Bevor sie vom eigenen Programm bearbeitet werden, gelangen sie in eine Ereignisschlange (engl. event queue). Jedem Fenster ist eine eigene Event-Queue zugeordnet. Diese Event-Queue ist für Programmierer zugänglich und in einer plattformunabhängigen Klasse EventQueue implementiert. Elemente der Klasse sind Objekte vom Typ AWTEvent. Ein eigener Thread, der AWT-Event-Thread, läuft parallel zur Anwendung und arbeitet die angesammelten Ereignisse dieser Warteschlange ab.

Der AWT-Thread führt auch den Programmcode in den Listenern aus. Aus diesem Grund ist es ungünstig, in einen Event-Handler lang dauernden Programmcode zu legen, denn dann »steht« die grafische Applikation und lässt sich nicht fortsetzen, weil der AWT-Thread blockiert ist. Bei einer längeren Aktion in einem Event-Handler sollten wir einen separaten Thread starten, damit die grafische Oberfläche sofort wieder reaktionsfähig ist.

Beispiel

Wenn eine Schaltfläche angeklickt wird, soll ein langer Text in den Puffer eingelesen werden:

ActionListener al = new ActionListener() {
public void actionPerformed( ActionEvent e ) {
new Thread( new ReaderThread(e.getActionCommand()) ).start();
}
};

In einer externen Klasse lesen wir zum Beispiel einen Text:

class ReaderThread implements Runnable
{
ReaderThread( String actionCommand )
{
// ...
}
public void run() {
// ...
}
}

Eine Alternative ist der SwingWorker, den wir später in Abschnitt 9.25.4, »SwingWorker«,
vorstellen.

Unter dem AWT ist es kein Problem, wenn zwei Threads auf ein und dasselbe Oberflächenelement zugreifen. Bei Swing ist dies jedoch etwas anders, wie wir im nächsten Abschnitt sehen werden.


Rheinwerk Computing - Zum Seitenanfang

9.25.2 Swing ist nicht thread-sicherZur nächsten ÜberschriftZur vorigen Überschrift

Die Tatsache, dass das Swing-Toolkit nicht thread-sicher ist, erstaunt vielleicht auf den ersten Blick. Das AWT ist thread-sicher, da AWT auf Plattform-Peer-Elemente vertraut. In einer List-Box unter dem AWT ist es problemlos möglich, ein Element einzufügen und parallel zu löschen. Doch auf die Synchronisation bei Swing wurde aus zwei Gründen verzichtet:

  • Operationen können in Threads zu ärgerlichen Deadlock-Situationen führen.
  • Der Verzicht auf Synchronisation kann die Ausführungsgeschwindigkeit erhöhen.
Hinweis

Gibt es konkurrierende Zugriffe auf Swing-Komponenten, kann es zu Exceptions der Art »Exception in thread "AWT-EventQueue-0"« kommen.

Swing weiß mit konkurrierenden Zugriffen nicht allzu viel anzufangen

In einem kleinen Beispiel wollen wir genau einen Fehler provozieren, in dem zwei Threads gleichzeitig eine Datenstruktur modifizieren und somit Swing aus dem Takt werfen. Es ist ein mahnendes Beispiel, Operationen an GUI-Komponenten nur über den AWT-Event-Thread vorzunehmen:

Listing 9.89: com/tutego/insel/ui/swing/SwingNoSyncDemo.java

package com.tutego.insel.ui.swing;

import javax.swing.*;

public class SwingNoSyncDemo
{
public static void main( String[] args )
{
final DefaultListModel<String> model = new DefaultListModel<String>();

JFrame frame = new JFrame();
frame.add( new JList<String>( model ) );
frame.setSize( 200, 100 );
frame.setVisible( true );

new Thread() {
@Override public void run() {
setPriority( Thread.MIN_PRIORITY );
while ( true )
model.addElement( "Dumm gelaufen" );
}
}.start();

new Thread() {
@Override public void run() {
setPriority( Thread.MIN_PRIORITY );
while ( true )
model.removeElement( "Dumm gelaufen" );
}
}.start();
}
}

Werfen wir einen Blick auf die Ausgabe, die erscheint, wenn das Programm nur kurz läuft:

Exception in thread "AWT-EventQueue-0" Zeilenumbruch
java.lang.ArrayIndexOutOfBoundsException: 5891 >= 5891
at java.util.Vector.elementAt(Vector.java:427)
at javax.swing.DefaultListModel.getElementAt(DefaultListModel.java:70)
at javax.swing.plaf.basic.BasicListUI.updateLayoutState(BasicListUI.java:1348)
...
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

Obwohl das DefaultListModel als unterliegende Datenstruktur den Vector nimmt und dieser nur synchronisierte Methoden besitzt, die beim nebenläufigen Zugriff den Vector nicht irritieren, ist er nicht der Übeltäter. Es liegt an Swing, wie mit den Daten umgegangen wird. Wenn der erste Thread Daten in das Model einfügt, muss die Visualisierung aktualisiert werden. Wir wissen von DefaultListModel, dass es über ListDataEvent das Darstellungsobjekt informiert, wenn es den Inhalt neu zeichnen muss. Merken wir uns die Stelle. Das Darstellungsobjekt wird sich nun vom Model die Daten besorgen. Bis dahin läuft alles ganz gut. Doch der zweite Thread löscht parallel die Daten aus dem Model. Springen wir jetzt zur Markierung zurück. Irgendwann passiert es, dass zwischen der Benachrichtigung der Darstellungskomponente und dem wirklichen Zeichnen sowie der Anfrage an das Model etwas gelöscht wird. Die Visualisierung weiß davon aber nichts und versucht, alle Werte zu zeichnen; es fehlt jedoch mindestens ein Wert. Daher folgt eine ArrayIndexOutOfBoundsException in der Methode elementAt() vom Vector. Die Visualisierung fragt mit einem Index im Vector nach, doch der Vector hat vom Lösch-Thread schon ein Element abgeben müssen. Daher ist die interne Größe des Vektors kleiner als der von Swing erfragte Index.

Erlaubte Methoden

Einige der Methoden sind thread-sicher und dürfen von beliebigen anderen Threads aufgerufen werden:

  • der Aufruf zum Neuzeichnen mit repaint() oder revalidate() für die Größenänderung einer Komponente im Container
  • alle Aufrufe auf neuen Komponenten, die noch nicht etwa mit setVisible() (früher show()) bzw. pack() veröffentlicht wurden
  • Die Eintragung von Listenern, etwa bei JComponent mit den Methoden addPropertyChangeListener(), removePropertyChangeListener() und addVetoableChangeListener(), removeVetoableChangeListener() ist sicher.
  • Bei JCheckBoxMenuItem ist es dann die einsame Methode setState(boolean), die synchronisiert ist. Es findet sich intern mal hier, mal da ein synchronisierter Block.

Ansonsten ist jedoch nicht viel dabei, und wir müssen unsere Teile synchronisiert ausführen. Um Programmstücke konform ausführen zu lassen, definiert Swing einige Methoden und Klassen. Dazu gehören:

  • invokeLater(Runnable)
  • invokeAndWait(Runnable)
  • JProgressBar
  • ProgressMonitor
  • ProgressMonitorInputStream
  • SwingWorker

Rheinwerk Computing - Zum Seitenanfang

9.25.3 invokeLater() und invokeAndWait()Zur nächsten ÜberschriftZur vorigen Überschrift

Da Swing nicht thread-sicher ist, bietet der AWT-Thread die einzige Möglichkeit zur Manipulation von Oberflächenelementen. Wenn wir es schaffen, dort die Aufträge einzureihen, dann wird nichts schiefgehen. Genau für diese Aufgabe gibt es in der Klasse EventQueue zwei statische Methoden: invokeLater() und invokeAndWait(). Damit lassen sich beliebige Programmstücke in die Warteschlange einführen. In der Warteschlange für das AWT liegen Aufträge und Ereignisse, die an die Oberflächenelemente verteilt werden. Alles spielt sich dabei neben dem Haupt-Thread ab, sodass Parallelität herrscht. Hat die Warteschlange alle Ereignisbehandler aufgerufen, kann der Programmcode von invokeLater() und invokeAndWait() durchlaufen werden.

Die beiden Methoden erfüllen unterschiedliche Bedürfnisse:

  • invokeLater() legt einen Runnable in die Warteschlange und kehrt sofort zurück. Die Funktion ist somit asynchron. Der Aufrufer weiß nicht, wann der Programmcode abgearbeitet wird.
  • invokeAndWait() legt ebenfalls einen Runnable in die Warteschlange, verharrt aber so lange in der Funktion, bis der Programmcode in run() aufgerufen wurde. Die Funktion ist also synchron.

Mit diesen statischen Methoden lassen sich jetzt alle Manipulationen an der Oberfläche durchführen. Den statischen Methoden wird ein Runnable-Objekt übergeben, was den Programmcode repräsentiert, der im AWT-Event-Thread auszuführen ist.

Beispiel

Ein Fortschrittsbalken JProgressBar mit dem Namen bar soll aus einem Nicht-AWT-Event-Thread einen Wert gesetzt bekommen:

EventQueue.invokeLater( new Runnable()
{
public void run() {
bar.setValue( i );
}
} );

Bei der Auswahl der beiden Methoden haben wir uns für den Fortschrittsbalken für invokeLater() entschieden. Es ist in der Regel wenig sinnvoll, die Methode so lange stehen zu lassen, bis die Anzeige auch wirklich gezeichnet wurde.

Ein Problem stellt für sehr viele Applikationen leider die Tatsache dar, dass das Objekt zur Manipulation immer irgendwie sichtbar sein muss. Hier soll bar einfach direkt für die innere Klasse sichtbar sein.

Die Methoden invokeLater() und invokeAndWait() befinden sich nicht nur in der Klasse EventQueue, sondern sind noch einmal in der Klasse SwingUtilities untergebracht. Daher ist es gleichgültig, ob wir EventQueue.invokeXXX() oder SwingUtilities.invokeXXX() schreiben. SwingUtilities hat vielleicht den Vorteil, dass das Paket java.awt für die EventQueue nicht importiert werden muss, sonst gibt es aber keinen Unterschied.

Hinweis

Einige Entwickler setzen den Programmcode der main()-Methode zum Aufbau eines JFrames ebenfalls in einen invokeLater()-Block, etwa so:

SwingUtilities.invokeLater( new Runnable() {
public void run() {
JFrame f = new JFrame( "Uhrzeit" );
f.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
f.add( new JLabel( String.format( "%tT", new Date() ) ) );
f.setSize( 250, 100 );
f.setVisible( true );
}
} );

Obwohl ein new JFrame() schon den AWT-Event-Thread setzt, muss erst ab der Programmzeile mit setVisible() alles abgesichert werden.[77](http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html) Die Beispiele in diesem Buch sind also vom Standpunkt der AWT-Threadings völlig in Ordnung.

Implementierung

Genehmigen wir uns abschließend noch einen kurzen Blick auf die Implementierung. Es lässt sich schon erahnen, dass invokeLater() einfacher ist:

public static void invokeLater( Runnable runnable )
{
Toolkit.getEventQueue().postEvent(
new InvocationEvent(Toolkit.getDefaultToolkit(), runnable) );
}

Das Ereignis, das in die Event-Queue kommt, ist vom Typ InvocationEvent und damit ein AWTEvent. Wir übergeben unser Runnable-Objekt, damit der AWT-Thread später die run()-Methode aufrufen kann.

Die statische Methode invokeAndWait() ist etwas komplizierter; wir wollen von der Implementierung nur wenige Zeilen betrachten. Im Prinzip leistet die Methode das Gleiche wie invokeLater(); auch sie muss das InvocationEvent in die Warteschlange legen. Hinzu kommt jedoch, dass invokeAndWait() auf das Ende des Threads warten muss:

InvocationEvent event = new InvocationEvent(
Toolkit.getDefaultToolkit(), runnable, lock, true);
synchronized (lock) {
Toolkit.getEventQueue().postEvent(event);
lock.wait();
}

Das konstruierte InvocationEvent bekommt als Argument wieder das runnable. Jetzt erhält es aber zusätzlich ein Lock-Objekt. Wenn der AWT-Thread durch die Ereignis-Warteschlange geht und das InvocationEvent sieht, führt er wieder die run()-Methode aus. Anschließend informiert er über notify() das wartende Objekt. Dann steigt invokeAndWait() aus dem synchronized-Block aus, und es geht weiter.


Rheinwerk Computing - Zum Seitenanfang

9.25.4 SwingWorkerZur nächsten ÜberschriftZur vorigen Überschrift

Mit er Klasse SwingWorker ist es einfach möglich, längere Programmteile im Hintergrund von einem Nicht-AWT-Thread abarbeiten zu lassen und dann später die Ergebnisse über den AWT-Thread wieder in die GUI einfließen zu lassen. Die Klasse ist ab Java 6 Teil der Java SE, für frühere Java-Versionen liegt eine Version mit Dokumentation unter https://swingworker.dev.java.net/ vor.

Für einen eigenen SwingWorker ist zunächst eine Unterklasse von javax.swing.SwingWorker zu bilden. Wir wollen eine Klasse ClockPrecision angeben, die zwei Sekunden wartet und dabei die Zeit misst – das Ergebnis ist durch Ungenauigkeit nicht wirklich zwei Sekunden. Wir interessieren uns hier für die Ungenauigkeit. Nach Ablauf der Zeit soll der SwingWorker das Ergebnis auf die Schaltfläche schreiben, die auch der Auslöser für die Warterei ist:

Listing 9.90: com/tutego/insel/ui/event/SwingWorkerDemo.java

package com.tutego.insel.ui.event;

import java.awt.event.*;
import javax.swing.*;

public class SwingWorkerDemo extends JFrame
{
JButton button = new JButton( "Change my mind!" );

SwingWorkerDemo()
{
setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
add( button );

ActionListener al = new ActionListener() {
@Override public void actionPerformed( ActionEvent e )
{
new ClockPrecision().execute();
}
};

button.addActionListener( al );

pack();
}

class ClockPrecision extends SwingWorker<Long, Object>
{
@Override public Long doInBackground()
{
long startNano = System.nanoTime();
try { Thread.sleep( 2000 ); } catch ( InterruptedException e ) { }
return (System.nanoTime() – startNano ) / (1000*1000);
}

@Override protected void done()
{
try
{
button.setText( "" + get() );
}
catch ( /* InterruptedException, ExecutionException */ Exception e ) { }
}
}

public static void main( String[] args )
{
new SwingWorkerDemo().setVisible( true );
}
}

Die Methode done() bekommt die Rückgabe von doInBackground() über die get()-Methode. Unser SwingWorker durchläuft mehrere Phasen, an denen wir uns durch Überschreiben einiger Methoden aktiv beteiligen:

  • Es beginnt mit execute(), was den SwingWorker dazu bewegt, einen sogenannten Worker-Thread aufzubauen.
  • Der Worker-Thread ruft doInBackground() auf, in den wir unseren im Hintergrund auszuführenden Programmteil setzen. Der Rückgabetyp ist durch die generische Verwendung frei wählbar. Da SwingWorker auch vom Typ Future ist, kann das Ergebnis einer Berechnung get() liefern. Sind mit addPropertyChangeListener() neue PropertyChangeListeners angemeldet, können wir sie mit firePropertyChange() aufrufen und während der Verarbeitung Status-Ereignisse schicken. publish() erlaubt das Absenden von Zwischenergebnissen, die sich unter dem AWT-Event in process() verarbeiten lassen. Dieser Typ kann ein anderer als der von get() sein, und so bestimmt die zweite Typvariable der generischen Klasse diesen Typ.
  • Am Ende des Worker-Threads kommt es im AWT-Event-Thread zu einem Aufruf von done(), wo wir unsere Swing-Operationen vornehmen können.

Weiteres ist der API-Dokumentation zu entnehmen.


Rheinwerk Computing - Zum Seitenanfang

9.25.5 Eigene Ereignisse in die Queue setzen *Zur nächsten ÜberschriftZur vorigen Überschrift

Es ist ohne großen Umweg möglich, eigene Ereignisse zu erzeugen und in der EventQueue zu platzieren. Damit lassen sich beispielsweise Eingaben des Benutzers emulieren. Da alle Ereignisse von Komponenten von AWTEvent erben, lässt sich ein ActionEvent erzeugen, das dann wiederum von einem interessierten Listener entgegengenommen wird. Jetzt fehlt uns nur noch eine Methode, die Ereignisse in die Schlange setzt. Dazu bietet die Klasse EventQueue die Methode postEvent() an. Im Beispiel sehen wir die notwendigen Aufrufe, um beginnend vom Toolkit an die SystemEventQueue zu kommen:

Toolkit.getDefaultToolkit().getSystemEventQueue().
postEvent(
new ActionEvent( /* Object source, int id, String command */ )
);
class java.awt.Toolkit
  • final EventQueue getSystemEventQueue()
    Liefert ein Exemplar der EventQueue für eine Applikation oder ein Applet. Eine SecurityException wird ausgelöst, falls der Security-Manager den Zugriff auf EventQueue verbietet.
class java.awt.EventQueue
  • void postEvent(AWTEvent theEvent)
    Legt ein Ereignis in die EventQueue. Danach werden vorhandene EventQueueListener und notifyEventQueueListener aufgerufen.

Einer Komponente ein Ereignis schicken

Ist die Komponente bekannt, der ein Ereignis geschickt werden soll, lässt sich die Component-Methode dispatchEvent(AWTEvent e) verwenden. Sie sendet ein AWTEvent – die Basisklasse aller AWT-Ereignisse – an die Komponente, womit alle Listener aufgerufen werden. Für die Aktivierung einer Schaltfläche b lautet es dann:

b.dispatchEvent( new ActionEvent(b,ActionEvent.ACTION_PERFORMED, "text") );

Rheinwerk Computing - Zum Seitenanfang

9.25.6 Auf alle Ereignisse hören *Zur vorigen Überschrift

Um keine Ereignisse zu versäumen, lässt sich über das Toolkit ein Super-Listener anmelden. Dieser Listener ist vom Typ AWTEventListener, der über addAWTEventListener() mit dem Toolkit verbunden wird:

AWTEventListener ael = new AWTEventListener() {
public void eventDispatched( AWTEvent event ) {
}
};
Toolkit.getDefaultToolkit().addAWTEventListener( ael, mask );

Die mask bestimmt den Typ eines jeden gemeldeten AWTEvent. Hier kann für Mausbewegungen etwa AWTEvent.MOUSE_MOTION_EVENT_MASK stehen.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
  Zum Katalog
Neuauflage: Java SE 8 Standard-Bibliothek
Neuauflage: Java SE 8 Standard-Bibliothek
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Professionell entwickeln mit Java EE 7






 Professionell
 entwickeln mit
 Java EE 7


Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: Einstieg in Eclipse






 Einstieg in Eclipse


Zum Katalog: Einstieg in Java






 Einstieg in Java


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das 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.


Nutzungsbestimmungen | Datenschutz | Impressum

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