Swing Swing und Edt

[ARadauer]

Ich muss ehrlich sagen, dass ich bis vor Kurzem die Problematik mit dem Event Dispatcher Thread nicht wirklich verstanden habe... jetzt lese ich gerade filthy rich clients und jetzt wird die Sache klarer...

also:
1. Immer wenn ich Swing Komponenten bearbeite, erzeuge usw.. sollte das im EDT geschehen
2. Immer wenn ich Dinge mache die nicht Swing betreffen (Fachlogik) sollte das nicht im EDT geschehen

also sowas ist vollkommen falsch

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.JButton;
import javax.swing.JFrame;


public class Test extends JFrame implements ActionListener
{
	
	public static void main(String[] args){
		Test f = new Test();
		JButton button = new JButton("test");
		button.addActionListener(f);
		f.add(button);
		f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		f.pack();
		f.setVisible(true);
	}

	public void actionPerformed(ActionEvent e){
		System.out.println("Button wurde geklickt");
		System.out.println("berechnungs usw...");
		try{
			Thread.sleep(2000);
		}catch (InterruptedException e1){}
		System.out.println("fertig");		
	}

}

aber nicht nur, weil die Berechnung im Edt ausgeführt wird... sondern auch weil das Erzeugen der Gui Kommponenten nicht im EDT ausgeführt wird oder?

so würde es richtig sein, oder?

import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.SwingUtilities;


public class Test extends JFrame implements ActionListener{
	
	public static void main(String[] args){
		
		SwingUtilities.invokeLater(new Runnable(){
			
			@Override
			public void run(){
				Test f = new Test();
				JButton button = new JButton("test");
				button.addActionListener(f);
				f.add(button);
				f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
				f.pack();
				f.setVisible(true);				
			}
		});		
	}

	public void actionPerformed(ActionEvent e){
		new Thread(new Runnable(){			
			@Override
			public void run(){
				System.out.println("Button wurde geklickt");
				System.out.println("berechnungs usw...");
				try{
					Thread.sleep(2000);
				}catch (InterruptedException e1){}
				System.out.println("fertig");	
				
			}
		}).start();			
	}
}

aber sorry, ist dann swing nicht irgendwie eine fehlkonstruktion?

Immer wenn ein event erzeug wird und ich in den meisten fällen fachlogik ausführe muss ich einen thread erzeugen? Warum kann das swing nicht für mich machen?

Immer wenn ich Gui Komponenten erzeuge muss ich das explizit mit SwingUtilities.invokeLater machen? Auch nicht sehr intuitiv...

Was sagt ihr dazu?

 

[andiv]

Der Hintergrund hinter dem ganzen ist ja, dass Swing nicht threadsafe ist und dass es auch nicht sinnvoll ist eine multithreading-fähige GUI-Bibliothek zu schreiben. Der Ansatz alle Zugriffe auf GUI-Elemente nur im EventDispatcherThread zu machen hat sich eben durchgesetzt.

Daraus folgt wie du richtig erkannt hast, dass du die Initialisierung der GUI auch schon im EDT machen solltest mit SwingUtilities.invokeLater(...).

Der Code in den ActionListenern wird von Swing automatisch im EDT ausgeführt, damit du problemlos auf die GUI-Elemente zugreifen kannst, was du ja in den meißten Fällen auch willst. Du kannst auch ohne Weiteres Berechnungen im EDT durchführen.

Der Punkt ist halt, dass wenn deine Berechnungen lange dauern, dass dann die GUI nicht mehr reagiert, weil du eben den EDT blockierst. Deshalb solltest du längere Berechnungen in einem Hintergrundthread ausführen, damit die GUI weiterhin flüssig reagiert. Dabei hilft dir die Klasse SwingWorker, die auch die Rückgabe von Ergebnissen erleichtert um dann im EDT wiederum die GUI zu aktualisieren.

Ja, ich finde auch, dass das ziemlich umständlich klingt, aber nach allem was ich bisher gelesen habe, scheint es noch keinen besseren Ansatz für das ganze zu geben.

 

[Landei]

Closures in Java 1.7 können das Problem entschärfen, aber im Prinzip hast du recht, es ist umständlich. Aber du bringst mich auf eine gute Idee: In meinem Projekt Swirrel könnte ich auch "Listener im neuen Thread" anbieten, wie actionPerformed in deinem korrekten Beispiel.

 

[Marco13]

Hmja. Speziell das Erzeugen ist kein so großer Aufwand: Man hat üblicherweise EINE Stelle, wo das GUI gebaut wird, und diese eine Stelle wickelt man in SwingUtilities ein. Wenn später noch Components hinzukommen, und meistens auch bei anderen Änderungen, passiert das ohnehin aufrund von anderen Aktionen, die schon über den EDT laufen (Z.B. Buttonklick -> Neues Fenster aufmachen oder so). Wenn nicht, macht man eben ein SwingUtilities drum - das ist auch recht kompakt und einfach.

Die umgekehrte Richtung ist in letzter Konsequenz ein bißchen... diffiziler. Wenn man ein Threadsicheres Modell hat, kann man das auch vom EDT aus verändern - sofern die Veränderung nicht lange dauert. Natürlich kann man das ggf. nicht immer mit Bestimmtheit sagen. Sowas wie [c]model.setSomeFlag(true);[/c] kann man auch direkt vom EDT aus machen. Sowas wie [c]model.readFromDataBase(hugeThing);[/c] eher nicht. Für solche Sachen gibt es mit dem SwingWorker aber ein Werkzeug, das einem da einiges an Arbeit abnimmt.

Ansonsten steht es jedem frei, ein besseres, Multi-Threading-Fähiges GUI Toolkit zu bauen. Wenn man nach der Lektüre von Multithreaded toolkits: A failed dream? | Java.net noch den Mut dazu hat

IMHO wird die Frage bei einem Punkt besonders interessant: Ein Modell läuft in einem Thread, und benachrichtigt auf diesem Thread seine Listener über seinen Fortschritt. Wenn einer der Listener eine Swing-Component ist (oder er eine solche verändert) muss er beim Aufruf der Listener-Methoden sicherstellen, dass der Event vom Modell-Thread auf den EDT umgebogen wird. Ich hatte da mal was gebastelt ... http://www.java-forum.org/awt-swing-swt/94565-model-listener-background-jobs.html#post600770 ... aber bin noch nicht zum dort angesprochenen "Aufbohren" gekommen... (@Landei: ... aber vermutlich würdest du in Swirrel dann soweiso schon sowas ähnliches machen... )

 

[ARadauer]

also allgemein sind wir uns über die Problematik einig... mann muss halt wissen was man tut

 

[Landei]

@Landei: ... aber vermutlich würdest du in Swirrel dann soweiso schon sowas ähnliches machen...

Nur um Missverständnisse zu vermeiden: Bei Swirrel geht es ausschließlich um Listener bzw. Actions, es hilft nicht im geringsten beim Aufbau der GUI, d.h. da muss man sich selber um die richtigen Threads kümmern. Was (zumindest konzeptionell) ganz einfach zu implementieren ist, ist die Möglichkeit, dass der Nutzer über einen Schalter an meinen Annotations sagt, wo der Listener-Code ausgeführt werden soll: Wie bisher im EDT oder in einem neuen Thread. Ich habe gerade meine Änderungen ins SVN eingecheckt - das war wirklich eine ziemliche Tipperei. Aber ich muss erst noch ein wenig testen und ein hübesches Beispiel schreiben, bevor ich ein neues Release mache.

 

[Marco13]

Ne, also bei mir lag da kein Mißverständnis vor. Ich hatte mir Swirrel noch nicht näher angesehen, aber schon erwartet, dass dort für die gleiche Funktionaliät, die mit dieser Proxy-Klasse erreicht wurde, im Endeffekt "nur" ein boolean (in diesem Fall 'treaded') irgendwo hinzugefügt werden müßte. ("nur" in Anführungzeichen, weil dieses 'irgendwo' sich dabei eben nicht auf nur EINE Datei bezog )

 

[Landei]

Korrekt. Statt

@ActionPerformed("meineMethode")

muss man nur

@ActionPerformed(value = "meineMethode", threaded = true)

schreiben, dann funktioniert es. Hier ist die Testklasse, in der die gleiche 10s lang blockierende Methode von zwei Buttons aufgerufen wird, einmal im EDT, einmal im neuen Thread.

 

[Gast2]

Die Porblematik bei SWT nicht anders. Außer dass man eine Exception bekomm wenn man auf GUI Elemente im flaschen Thread zugreift(was sehr gut ist), was bei Swing nicht der Fall ist.
In einem Framework(z.B. eclipse RCP) gibt es auch schon einige Klassen um diese Problematik angenehm und einfach zu gestalten.