Copyright (c) SEMM NL All rights reserved.
Author : Paul Hamaker. Part of


and the likes, updating the user interface, is no problem when you're using Swing components and you make these calls from actionPerformed, mouseClicked or other such event-handling methods.

These are usually called by the framework as part of the event-handling thread.

In our example however, calls that affect the GUI are made from a different thread and this requires special measures.

From our thread's run method we make calls to our updateGUI method.

This method ....

contains the calls we want to make ....

but these calls are not made.....

until this method deems fit.

The argument, doGUI, refers to this inner class, an implementation of the Runnable interface.

The parameters are regarded as local variables, local to the method. For use by the inner class, the compiler requires them to be final.




SwingUtilities is a class in javax.swing and the invokeAndWait method is static. That explains the syntax.


If you absolutely can't deduce if a method is in the event-handling thread, use this.


invokeAndWait throws an exception if it's called from the event-dispatching thread.


This can be called from any thread, but your code will merrily continue after this call, possibly without the GUI having been updated yet.

That's why invokeAndWait is described as being synchronous and invokeLater as asynchronous.