java.awt.EventQueue.invokeLater spiegato

Sono molto curioso perché dobbiamo usare java.awt.EventQueue.invokeLater per controllare i componenti swing.

Perché non possiamo farlo nel thread normale? Cosa sta succedendo esattamente dietro le quinte? Da quello che ho notato se ho un JFrame posso impostare la visibilità su true o false dal thread principale senza ottenere errori, e sembra funzionare. Quindi, che cosa realizzo esattamente utilizzando java.awt.EventQueue.invokeLater ? Sono anche pienamente consapevole che posso usare SwingUtilities.invokeLater ma, come spiegato qui , sembrano essere la stessa cosa.

Grazie a tutti per la loro spiegazione. Speriamo che questa sia una domanda valida.

EDIT: per rispondere alla domanda di wumpz Possiamo creare un jframe

 JFrame frame = new JFrame("Hello world"); frame.setSize(new Dimension(300, 300)); frame.setPreferredSize(new Dimension(300, 300)); frame.setMaximumSize(new Dimension(300, 300)); frame.setMinimumSize(new Dimension(300, 300)); frame.setVisible(true); frame.pack(); frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); 

E sullo stesso thread è stato creato fare quanto segue.

     for (int i = 0; i < 34; i++) { System.out.println("Main thread setting to "+(!frame.isVisible())); frame.setVisible(!frame.isVisible()); } 

    E nessuna lamencanvas.

    L’elaborazione Swing completa viene eseguita in un thread chiamato EDT (Event Dispatching Thread) . Pertanto si bloccherebbe la GUI se si calcolassero calcoli di lunga durata all’interno di questo thread.

    Il modo per andare qui è elaborare il tuo calcolo all’interno di un thread diverso, quindi la tua GUI rimane retriggers. Alla fine, si desidera aggiornare la GUI, che deve essere eseguita all’interno dell’EDT. Ora EventQueue.invokeLater entra in gioco. Pubblica un evento (il tuo Runnable ) alla fine dell’elenco degli eventi Swings ed è elaborato dopo che tutti gli eventi precedenti della GUI sono stati elaborati.

    Anche l’uso di EventQueue.invokeAndWait è ansible qui. La differenza è che il tuo thread di calcolo si blocca fino a quando la GUI non viene aggiornata. Quindi è ovvio che questo non deve essere usato dall’EDT.

    Fai attenzione a non aggiornare la tua GUI Swing da un thread diverso. Nella maggior parte dei casi ciò produce strani problemi di aggiornamento / aggiornamento.

    C’è ancora del codice Java là fuori che inizia una semplice JFrame dal thread principale. Ciò potrebbe causare problemi, ma non è impedito da Swing. Gli IDE più moderni ora creano qualcosa come questo per avviare la GUI:

     public static void main(String args[]) { java.awt.EventQueue.invokeLater(new Runnable() { public void run() { new NewJFrame().setVisible(true); } }); } 

    Tutte le piattaforms supportate offrono librerie grafiche a thread singolo. Swing è multipiattaforma. Pertanto, gli oggetti della GUI Swing dovrebbero essere costruiti e modificati solo sul thread di invio dell’evento .

    A parte, SwingUtilities.invokeLater() è una cover per EventQueue.invokeLater() dalla versione 1.3.