Why does my boilerplate Java desktop app JFrame use EventQueue.invokeLater in the main method?

Question

I am using the latest Eclipse, and GWT Designer, to make a swing application in Java. The main function in my application window (which is a javax.swing.JFrame) in the auto generated by the tools looks like this:

    /* launch the application */
public static void main(String[] args) {
    EventQueue.invokeLater(new Runnable() {
        public void run() {
            try {
                AppWindow window = new AppWindow();
                window.frame.setVisible(true);
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    });
}

This seems like a lot of noise around what could have been just this:

public static void main(String[] args) {
            try {
                AppWindow window = new AppWindow();
                window.frame.setVisible(true);
            } catch (Exception e) {
                e.printStackTrace();
            }


}

I have read that the EventQueue.InvokeLater technique is required in some situations, and another question asks where to use it here.

My question is simpler; Why do this automatically in the code generator here? Why should main return quickly and let the application window get created later by the event queue? Wouldn't blocking be exactly the point? Why is the JFrame auto-generated designer doing this EventQueue stuff? I have tried to see some difference in the start up and showing of forms whether this code is done the simpler way or the harder way, and I can only conclude provisionally that this has some benefits that are not visible in tiny demo apps made by beginners like me, and that perhaps in real-world large complex Jframe based classes, there is some benefit to this delaying/queuing strategy?

Answer 1

Depending on your application and how it's being used, it's possible that there could be something that is drawing on the screen (and thus using the EventQueue) before or during the call to your main method. Calls that modify any UI components should be made on the Event Dispatch Thread, and this includes setting the application visible.

So just to be safe, it's a good practice to start your application on the EDT.

Why do this automatically in the code generator here?

It won't hurt, it's easy to generate, and it's considered good practice.

Why should main return quickly and let the application window get created later by the event queue?

It's possible that the main method is being called from some other application that is using the EDT and may have already drawn something on screen. If you draw your application directly in main, it's possible that your application may be altering some component that is in the process of being handled by something on the EDT, and potentially already drawn on the screen.

So just to be safe in case this situation ever happens, you should leave it up to the EDT to draw your application so it can do it when it won't interfere with anything else.

Wouldn't blocking be exactly the point?

Unless something else is calling main other than the JVM process that your user started by double-clicking the desktop icon, it's not going to make a difference when main returns as long as there is something on the screen.

I can only conclude provisionally that this has some benefits that are not visible in tiny demo apps made by beginners like me

You're right - most of the time it's probably not gonna make a difference, but I presume they included it because it was easy to generate & implement, it can't hurt, and it would exemplify good practice.