What is SwingUtilities.invokeLater

Question

Possible Duplicate:
What does SwingUtilities.invokeLater do?
SwingUtilities.invokeLater

I have seen this little piece of code hundreds of times:

public static void main(String[] args) {
    javax.swing.SwingUtilities.invokeLater(new Runnable() {
        public void run() {
          createAndShowGUI();
        }
    });
}

Now my question is: what does invokeLater() do? What kind of bad things will happen if I just create and show my GUI inside the main thread?

Solution 1

Nothing bad will happen if you're updating it from the EDT while following guidelines.

That is...

If invokeLater is called from the event dispatching thread -- for example, from a JButton's ActionListener -- the doRun.run() will still be deferred until all pending events have been processed.

Source

If that isn't the case, invokeLater() is required.

It schedules a Runnable which will be executed on the EDT (event dispatching thread).

Solution 2

1. Event Dispatcher Thread is the GUI thread.

2. If you are talking about the main() method...then its not long lived in Java Gui. main() method after scheduling the construction of GUI in EDT quits, now its EDT that handles the GUI.

3. invokeLater means that this call will return immediately as the event is placed in Event Dispatcher Queue, and run() method will run asynchronously...

Solution 3

Swing is not thread-safe and all changes to Swing objects must be performed within the Event Dispatch Thread. If you try to run your code outside it, you'll get unspecified behavior, which will probably become weird at some point.

In contrast, the SWT/JFace GUI framework that Eclipse uses asserts the correct thread on each public entry point.

Comments

[assylias]

"If you try to run your code outside it, you'll just get an exception since the invoking thread is checked before any further actions" ? Running UI stuff outside of the EDT might create weird behaviour but will not necessarily throw an exception.

[11684]

Most of the time, you're doing everything from a thread. Do you mean not the main thread?

[kleopatra]

not only changes - each and every access (including instantiation) must be on the EDT

[kleopatra]

-1 for the nothing bad (unfortunately out off votes for today ;-) Please edit your answer to properly explain what you really mean.

[11684]

So if I put my code in invokeLater() that Runnable will be executed from the EDT and no 'weird behavior` (as stated by assylias) will be created? And what if I want to, say, update my JLabel's text? Should I officially put that in invokeLater() once again?

[assylias]

@11684 Yes you should, unless you know that you already are in the EDT.

[11684]

@assylias how would I know that?

[kleopatra]

hmm ... please consider using technical vocabulary so we all can understand what you really mean (not long lived or run simultaneously are not, which implies being either wrong or ambigous ;-)

[11684]

Found it, public static boolean isEventDispatchThread().

[Tomato]

@11684 however even if you are in the EDT, invokeLater will still work, so you might as well use it.

[assylias]

@11684 This post gives hints.

[Robin]

That exception is only the case in JavaFX, where they finally included that check. You can have similar behavior in Swing by using a custom repaint manager, as explained here

[Marko Topolnik]

@assylias and Robin, thanks for the correction. I work both with Swing and with SWT/JFace and I mixed them up.

[Steve Kuo]

"Nothing bad" isn't totally true. From SwingUtils.invokeLater "If invokeLater is called from the event dispatching thread -- for example, from a JButton's ActionListener -- the doRun.run() will still be deferred until all pending events have been processed.". So doing so from the EDT will cause your Runnable to run later than you probably want it to.

[nullpotent]

@SteveKuo Thank you for pointing that out. I updated my answer.