java.awt.EventQueue.invokeLater explicado

Tengo mucha curiosidad por qué tenemos que usar java.awt.EventQueue.invokeLater para controlar los componentes swing.

¿Por qué no podemos hacer eso en un hilo normal? ¿Qué está sucediendo exactamente detrás de escena? Por lo que he notado, si tengo un JFrame puedo establecer la visibilidad en verdadero o falso desde el hilo principal sin cometer ningún error, y parece que funciona. Entonces, ¿qué logro exactamente usando java.awt.EventQueue.invokeLater ? También soy plenamente consciente de que puedo usar SwingUtilities.invokeLater pero como se explica aquí , parecen ser una y la misma cosa.

Gracias a todos por su explicación. Espero que esta sea una pregunta válida.

EDITAR: para responder a la pregunta wumpz Podemos crear 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); 

Y en el mismo hilo que se creó, haga lo siguiente.

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

Y no tengo quejas

El procesamiento de Swing completo se realiza en un hilo llamado EDT (subproceso de envío de eventos) . Por lo tanto, bloquearía la GUI si calculó algunos cálculos de larga duración dentro de este hilo.

El camino a seguir aquí es procesar su cálculo dentro de un hilo diferente, para que su GUI permanezca receptiva. Al final, quiere actualizar su GUI, que debe hacerse dentro del EDT. Ahora entra en juego EventQueue.invokeLater . Publica un evento (tu Runnable ) al final de la lista de eventos de Swings y se procesa después de que se procesen todos los eventos GUI anteriores.

También el uso de EventQueue.invokeAndWait es posible aquí. La diferencia es que su hilo de cálculo se bloquea hasta que su GUI se actualice. Por lo tanto, es obvio que esto no debe usarse desde el EDT.

Tenga cuidado de no actualizar su GUI de Swing desde un hilo diferente. En la mayoría de los casos, esto produce algunos problemas extraños de actualización / actualización.

Todavía hay un código Java que inicia un JFrame simple desde el hilo principal. Esto podría causar problemas, pero no se lo impide a Swing. La mayoría de los IDEs modernos ahora crean algo como esto para iniciar la GUI:

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

Todas las plataformas compatibles ofrecen bibliotecas de gráficos de subproceso único. Swing es multiplataforma. Por lo tanto, los objetos de Swing GUI deben construirse y manipularse solo en el hilo de envío del evento .

Como un aparte, SwingUtilities.invokeLater() es una versión para EventQueue.invokeLater() desde la versión 1.3.