[Java - Swing] Due dubbi

[AngeL)]

leggendo qualche spezzone di codice java su internet mi è venuto un dubbio:
alcuni codici in swing sono scritti così:

public static void main(String[] args) {
EventQueue.invokeLater(new Runnable() { public void run() {
	//codice
}});
}

mentre altri sono scritti così

public static void main(String[] args) {
	//codice
}

ma cosa cambia? io ho sempre usato il secondo metodo e non ho mai avuto problemi

-secondo e ultimo

sempre leggendo spezzoni di codice, ne ho visti così

class MyProg {
	public static void main(String[] args) {
		MyFrame f = new MyFrame();
	}
}

class MyFrame extends JFrame {
	public MyFrame() {
		//codice
	}
}

e così

class MyProg {
	public static void main(String[] args) {
		JFrame frame = new JFrame();
		//codice
	}
}

voi quale usate e perchè?

[Mixmar]

Originariamente inviato da AngeL)

leggendo qualche spezzone di codice java su internet mi è venuto un dubbio:
alcuni codici in swing sono scritti così:

public static void main(String[] args) {
EventQueue.invokeLater(new Runnable() { public void run() {
	//codice
}});
}

mentre altri sono scritti così

public static void main(String[] args) {
	//codice
}

ma cosa cambia? io ho sempre usato il secondo metodo e non ho mai avuto problemi

Utilizzando il primo metodo puoi separare il thread principale della tua applicazione da quello demandato a disegnare la grafica swing: utilizzando il secondo metodo lo stesso thread svolge i due compiti, per cui può capitare, per esempio, che se la tua applicazione "si blocca" (perchè sta elaborando, per un errore, perchè in attesa dell'input di un utente eccetera), anche la grafica non venga ridisegnata, lasciandoti la ben nota finestrella "grigia" e vuota.
In questo senso, il primo metodo è preferibile al secondo.

[PGI-Bis]

Direi quasi. Prendiamo un caso concreto. Apertura di una finestra.

Usando la prima versione:

public static void main() {
    JFrame window = new JFrame("window");
    window.setVisible(true);
}

Una parte del lavoro necessario alla proiezione della finestra viene eseguito da un Thread diverso dall'EDT (il thread di cui parlava Angel). In particolare, il thread Main esegue una mutazione di stato, cioè cambia il valore di un campo di window. L'EDT entra in gioco automaticamente perchè è tramite l'edt che vengono "prelevate" le risorse native che consentono di avere una finestra in AWT/Swing.

L'inghippo sta nel fatto che la maggior parte del codice dei componenti AWT/Swing non è predisposto all'esecuzione concorrente.

Tra l'altro, gli stati (cioè i campi) dei componenti Swing non garantiscono la visibilità inter-thread delle proprie mutazioni. Non sono volatile o final o AtomicX per intenderci.

Se il Thread Main cambia lo stato di visibile a true e questo stato non è Thread-safe, allora esiste la possibilità che il Thread EDT trovi ancora il vecchio valore di visible.

E' una possibilità e non una certezza. Possibile perchè il linguaggio di programmazione Java dichiara quando una certa operazione ha un effetto inter-thread e lascia mano libera negli altri casi. La concreta implementazione del linguaggio può poi dire che tutte le mutazioni sono sempre visibili ma è un dettaglio su cui non possiamo fare affidamento.

Esiste anche una questione più grave. Il deadlock di cui parla Angel. E qui non dipende più dall'implementazione. Parte del codice di Swing/AWT, in particolare i LayoutManager, è sincronizzato: l'esecuzione di taluni blocchi è subordinata al controllo di un monitor. Un particolare incrocio di acquisizione dei monitor reciprocamente detenuti da due diversi Thread causa uno stallo sicuro del programma.

Qualche tempo fa Sun espose il problema dello stallo usando il thread principale semplicemente per aprire una finestra che conteneva una JTable.

Per questo motivo il secondo metodo:

public static void main...
EventQueue.invokeLater(...

oppure

SwingUtilities.invokeLater(...

non è preferibile al primo ma è semplicemente esatto mentre il primo è errato.

Ricordo che questo vincolo dell'esecuzione di codice all'interno dell'EDT, tramite invokeLater di EventQueue, deve essere rispettato in ogni caso in cui si voglia leggere o scrivere lo stato di un componente Swing proiettabile (cioè direttamente o indirettamente inserito in una finestra realizzata). Non solo nel main, quindi, ma anche in ogni altro punto del codice in cui non si possa dare per scontato che il Thread corrente sia l'EDT.

[andbin]

Originariamente inviato da AngeL)

ma cosa cambia?

http://java.sun.com/products/jfc/tsc.../threads1.html
http://java.sun.com/products/jfc/tsc.../threads2.html
http://java.sun.com/products/jfc/tsc.../threads3.html

I link rispondono a tutte le tue domande.