InvokeLater

I have read the documents about the EDT.
So I have a simple question:
Suppose you have a JFrame which contains just one JLabel.
Your application has a thread that receives datagrams from the net.
You want your JLabel to display the number of packets received.
So everytime a datagram packet arrives you have to use InvokeLater to repaint the JLabel? Isn't that too heavy?

I have an idea. Stick to invokeLater, but instead of instantiating a new Runnable every time you want to update, just instantiate a single Runnable object from a (non-anonymous) inner class that has access to the variable being changed, and then keep a reference to this Runnable kicking around. Then you can invoke invokeLater again and again with the same Runnable so you are not instantiating ten objects a second.
Like I said, I have never actually done anything like this but it is not a particularly bizarre thing you want to do.. so I am sure there is some way to do it without getting too exotic.
Actually my guess is that even if you just instantiate a new Runnable every darn time you will not notice any performance problems.
Drake

Similar Messages

Why do we have to use SwingUtilities.invokeLater() to update UI status?

I just don't understand very well why we have to use SwingUtilities.invokeLater() to update UI status. Why not just new a thread in actionPerformed() method and do time consuming tasks in this thread and update UI status in it? Some tutorials say it is not safe to update UI status not in Event Dispatch Thread, I don't understand, why is it not safe? Can anyone provide a scenario for this? I just write an example, a button and a progressbar, click button, progressbar keeps updating value. I just create a new thread to do this, don't find any issue. Thanks.

[Swing single threaded rule|http://www.lmgtfy.com/?q=swing+single+threaded+rule]
db

Should I use a SwingWorker or SwingUtilities.invokeLater() to update my UI?

Are there specific situations where you want to use method above the other? This whole swing concurrency is very new to me, and I don't really know where to begin.

When executing long running code you don't want the GUI to freeze. Therefore you have two things to be concerned about. First, you want the long running task to execute in a separate Thread. Secondly, when you need to update the GUI from this code you need to make sure the code executes on the Event Dispatch Thread (EDT).
You can code this manually by creating a separate Thread and then use SwingUtilities.invokeLater() when necessary.
A SwingWorker tries to simplify this process by having a simple API where you can add code that executes on a separate Thread or where you can add code that executes on the EDT.
So in the case of managing long running tasks, the end result should be the same.
Hwever, there are times when I know code is already executing on the EDT, but I sometimes use invokeLater(..) to force my code to the end of the EDT. This is used in special situations when code doesn't execute in the order you want.
For example, I've tried to add a FocusListener to a JFormattedTextField to "select the text" when it gains focus. The problem is the the UI also adds a FocusListener. Because of the way listeners are handled the last listener added to the component executes first. Therefore, using the invokeLater() forces my listener code to execute last.
You can try this code to see what I mean:
KeyboardFocusManager.getCurrentKeyboardFocusManager()
     .addPropertyChangeListener("permanentFocusOwner", new PropertyChangeListener()
     public void propertyChange(final PropertyChangeEvent e)
          if (e.getNewValue() instanceof JTextField)
               // invokeLater needed for JFormattedTextField
               SwingUtilities.invokeLater(new Runnable()
                    public void run()
                         JTextField textField = (JTextField)e.getNewValue();
                         textField.selectAll();
});Edited by: camickr on Mar 5, 2011 2:36 PM

Pass parameter to Runnable invoked by SwingUtil.invokeLater()

Hi there,
I just got trapped by a Threading problem in my SwingApplet:
The Applet parses XML Documents it receives from a Servlet and dynamically creates a GUI from that description, using Swing Components. (actually Applet and Servlet exchange a Queue of JAVA Objects, each representing a fraction of the complete GUI Description or causing the Applet to show a certain URL, for example)
Getting the XML Documents is done in an extra Thread (not the EventDispatchThread), since that might take a while. For doing the actual update of the Swing Components I use SwingUtilities.invokeLater(Runnable doc).
doc is my internal Representation of the GUI, doc.run() does the actual Parsing and GUI Updating.
My Question is: How can I pass doc the Message it has to parse in a way that subsequent calls to invokeLater(doc) (which - as I mentioned - are done in another Thread) cannot disturb the processing of the previous call?
My actual (pseudo-)code tries it this way:
Executed in Calling Thread:
private void callSwing(PWDocumentGui doc)
try
Iterator it = fromserver.getInqueue().iterator();
while (it.hasNext())
PWMessage msg = (PWMessage) it.next();
doc.setContent(msg);
Thread.sleep(2000); // makes it work for the moment - but thats extremely unsafe!!
it.remove();
catch (Exception e)
System.err.println(e);
Internal Document representing the GUI:
class PWDocumentGui extends Observable implements Runnable
private InternalModel internalmodel; // holds internal Model of GUI (Arrays of Swing Components
private String onemessage; // holds one message to be parsed: VALUE IS THE PROBLEM !
public void synchronized setContent(String themessage)
onemessage = themessage; // remeber the Message to be parsed
SwingUtilities.invokeLater(this) // call this.run() in EventThtead
// Called in Event Thread
// value of onemessage in the meantime might be overwritten by subsequent call to setContent().
public void run()
// do the parsing into the local and thus update internalmodel
parse(onemessage);
// Notify Observers (the Renderers registered as Observers of this) that they should update themselves
// accordicg to internalmodel
setChanged()
notifyObservers();
public InternalModel getModel() { return internalmodel; }
I suspect that the solution might be easy - for someone more relaxed...
This might be a question concerning design, not Swing, I think.
Thanks for any answer!
Uwe

Try creating an inner class which implements runnable.
Give the inner class members to hold the parameters you want to pass.
Implement the inner class's run() to check the variables and use them.
When calling invoke later create a new instance of the inner class, initialise the members for the parameter values and pass the inner class instance to invokeLater rather than the object of the main class.
In this way you get one copy of the parameters for every call to invoke later.

How careful do you need to be with SwingUtilities.invokeLater()

Is it safe to call an SwingUtilities.invokeLater() from within a method that was invoked with SwingUtilites.invokeLater() ?
I'll give a quick example below.
    public void setWindowLocation(final Point p) {
        //Throw this on to the ETD with a recursive method call.
        if(!SwingUtilities.isEventDispatchThread()){
            SwingUtilities.invokeLater(new Runnable(){
                public void run() {
                    setWindowLocation(p);
            //don't execute recursive call twice.
            return;
        }// end - EDT section.
        assert EventQueue.isDispatchThread():"Not Event Dispatch Thread";
        frame.setLocation(p);
        someOtherMethodThatCallsInvokeLater();
public void someOtherMethodThatCallsInvokeLater(){
      //be lazy don't bother to check if already on event dispatch thread.
       Runnable update = new Runnable(){
            public void run(){
                remoteModeWindow.setTransparency(50);
        SwingUtilities.invokeLater(update);
}What would happen would when the second method is called that didn't bother to see if it was already on the Event Dispatch thread, and just called invokeLater() anyway. Is that harmless, or can it lead to deadlock, or some other inefficiency?
The reason I ask, is I've seen some code in one class check and some in a different class that previously was only called from a non-dispatch thread never bothered to check. It is now possible that the "don't bother to check" method could be called in either situation (i.e. from a dispatch thread, or non-dispatch thread).
Comments appreciated. What is a general guideline for this situation? Too many of the Swing books I've seen only lightly cover a few pages on this topic.
Edited by: asnyder on Jul 2, 2009 7:14 PM

Calling invokeLater(...) in this manner is absolutely safe with regards to deadlocks. What happens is that your runnable is enqueued at the end of the event queue. There is a possibility that another runnable has been dispatched in the mean time, so there is no guarantee that your code will be executed immediately:
1. EDT enters someOtherMethodThatCallsInvokeLater()
2. Another event (from another thread) triggers a repaint for a component or some other UI operation, which is enqueued
3. Your runnable is enqueued on the EDT
So highly theoretically there may be a delay which could be avoided if you immediately executed the runnable:
public void someOtherMethodThatCallsInvokeLater(){
       Runnable update = new Runnable(){
            public void run(){
                remoteModeWindow.setTransparency(50);
        if (SwingUtilities.isEventDispatchThread())
            update.run();
        else
            SwingUtilities.invokeLater(update);
}In my experience though this kind of 'optimization' has no practical implications whatsoever.

Help on invokelater and invokeandwait

Hello,
i am developing an application using swing API.
in this application i have to read ceratin data from the database. and do operation on the data.
what i want to do is to fetch data based on a query and display the data to the user in a JTable on a separate JFrame. the user selects the row from the table, he wants to process and presses the select button on this frame, to set the static variable (say ROW_ID) in the class whcih invoked this frame.
now what should happen is that the invoking class object should wait untill i press the select button (ie when the ROW_ID is set).
i would like to know how to do it.
please help
thank you
Message was edited by:
vaibhavpingle

now what should happen is that the invoking class object should wait untill i press the select button (ie when the ROW_ID is set).
It doesn't sound like you want invokeLater() or invokeAndWait().
I think you want one of two things: the more likely is that you want to be using a modal JDialog to allow the user to select a row (if you display the table, make the selection and then close that new window). The other possibility is that you want your original object to have state, which is modified (on the Event Dispatch Thread) when the user makes the row selection. Until that state is modified, certain functionality is disabled.
i also tried to use the invokeAndWait(runnable) method but i got an exception saying that the call cannot be made
What exception? I don't know of one which says "the call cannot be made."

Difference between different invokeLater() methods

What is actually the difference between:
SwingUtilities.invokeLater()
EventQueue.invokeLater()
Are there other classes that implements the invokeLater() method?

Use the frigging source, Luke.
javax.swing.SwingUtilities:
    public static void invokeLater(Runnable doRun) {
     EventQueue.invokeLater(doRun);
    }

Question on SwingUtilities.invokeLater

The program I have included is attempting to "simulate" opening and loading a file into memory.
Run the program, select File and then select Open. You will notice that the File menu does not disappear for 3 seconds (i.e. until the file has been completely read).
I was hoping it was possible to close the File menu while the file is being read. While reading through various documentation on the invokeLater() method I found the following:
"Both invokeLater() and invokeAndWait() wait until all pending AWT events finish before they execute"
Therefore by adding an invokeLater() method I was hoping to accomplish the following series of events:
1) click on Open menuItem
2) invoke OpenAction
3) do the "repaint" (which would cause the file menu to disappear)
4) finish the OpenAction
5) do the long running task
Hopefully you understand what I am trying to accomplish and can provide some guidance. Here is the sample program:
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class TestInvokeLater extends JFrame
     JFrame frame;
     JMenuBar menuBar;
     JMenu menu;
     JMenuItem menuItem;
     public TestInvokeLater()
          frame = this;
          setDefaultCloseOperation( EXIT_ON_CLOSE );
          menuBar = new JMenuBar();
          menu = new JMenu("File");
          menuBar.add(menu);
          menuItem = new JMenuItem( new OpenAction() );
          menu.add(menuItem);
          setJMenuBar( menuBar );
          JPanel panel = new JPanel();
          panel.setPreferredSize( new Dimension( 100, 100 ) );
          setContentPane( panel );
     class OpenAction extends AbstractAction
          public OpenAction()
               putValue( Action.NAME, "Open" );
          public void actionPerformed(ActionEvent e)
          repaint();
     SwingUtilities.invokeLater(new Runnable()
     public void run()
          try
               Thread.sleep(3000); // simulate log running task
          catch (Exception e) {}
     public static void main(String[] args)
          JFrame frame = new TestInvokeLater();
          frame.pack();
          frame.show();
}

Thanks for the input, but I still have some confusion -
"invokeLater() simply appends the thread to the end of the dispatch queue, this happens before the event code to hide the file menu gets queued"
This is the part that confuses me. If I understand event driven programming correctly then the code for the MenuItemClicked must complete execution before the next event in the queue can be executed.
If we assume the code for MenuItemClicked is something like:
1) fireActionEvent
2) fireCloseMenuEvent
When MenuItemClicked is finished executing the next event in the queue is the ActionEvent which invokes my ActionPerformed code:
1) I use the Swing invokeLater() method (which means it should be queued "after" the fireCloseMenuEvent
Does this make any sense?

Why do we have to call SwingUtilities.invokeLater()??

Hello,
i am not understanding the concept of SwingUtilities.invokeLater() i read the documentation but still couln't get why it is needed and when it is needed?do we have to call this function everytime some event is generated and some action is performed on component Ex.mouse click on button etc?? Please give me little details regarding it's concept!
Thanks in advance :)

(guys correct me if i'm wrong here)Most of the time that's correct, but for some customizations it is necessary to run custom code after all default code contained in the Swing classes has been executed. For example, to request focus be given to a component that would otherwise not be immediately focused, if you omit to enclose that in a invokeLater, it will get the focus but immediately lose it as still-queued events mandate the transfer of focus elsewhere. Moreover, as the event delivery mechanism is asynchronous, the behavior may be inconsistent.
In general, any customization that may conflict with the normal flow should be wrapped in invokeLater, whether run from the EDT or another thread. The exceptions here are methods which the API declares to be thread safe.
what you want to do is run that time consuming process in a thread, and when you need to call back to update the GUI, then use SwingUtilities.invokeLater.Or use SwingWorker, that's what it's for.
cheers, db

Exception during event dispatching - Dont want to use Swing.invokeLater()

I am getting NullpointerException while event dispatching. I am using threads, where each thread executes soem functions and one synchonized method to update graphics (table.updateUI())
I am using thread.start to invoke the threads and not SwinUtilities.invokelater(). I know this is the problem because threads which update graphics should be invoked by invokelater, so that they are in queue in the awt event thread.
But the method that updates gui is a synchonized method, so there should not be any collision. Also invokelater runs through all the threads and then invokes each, this reduces performance.
Any help is very much appreciated.
Thanks,
JavaSeems.

Hi Teka,
Thanks for the response.
Ok following is the exception i get :-
Exception occurred during event dispatching:java.lang.NullPointerException at sun.awt.RepaintArea.paint(RepaintArea.java:300) at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:196) at java.awt.Component.dispatchEventImpl(Component.java:2663) at java.awt.Container.dispatchEventImpl(Container.java:1213) at java.awt.Component.dispatchEvent(Component.java:2497) at java.awt.EventQueue.dispatchEvent(EventQueue.java:339) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:131)
I read soem thread stuff and soem forums, all say that whenever thread updates gui, dont invoke them using start method, use invokelater. But that degrades performance, also all threads dont run simulanouelsy.
There will be a minimum of 6 threads in my program which will run for the lifetime of the dialog, so i need all of them to run simulatenoussly. But invokelater queues them in the awt evnt thread one after the other, and they dont run together.
The thread will update gui by methods like tabelmodel.updateRow, Table.updategui. I see exceptions after these statements.
Does this info help?

What is the advantage of using EventQueue.invokeLater ?

Hi, what is the advantage of using
public static void main(String args[]) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {
                new MainForm().setVisible(true);
}over
public static void main(String args[]) {
     new MainForm().setVisible(true);
}

You can update the GUI components in any thread. However their behaviour is not always correct if you do so.
Using invokeLater ensures that the GUI thread performs changes to the GUI components and draws them correctly.

Use of SwingUtillities.invokeLater

While reading through the Java Tutorial section on SWING, I noticed that it recommended to always use SwingUtillities.invokeLater for all of the code involved in setting up the GUI.
I recently converted two of my programs that I have been working on using this, and I'm coming up with a small problem:
The GUI will not appear in the Frame. At least, not until I resize the Frame (which would of course trigger the frame to re-layout and re-draw it's components). This has happened in BOTH of my programs that I modified this way.
They are VERY LARGE programs, so I can't post all the code, but has anybody ever come across this problem before? Does anybody know what I might be doing wrong?
Does that fact that my gui is an applet cause this problem? Does the init method already take care of this? Also, I make use of the MainFrame class from the Java 3D API to run it as stand-alone. Could that be causing the problem?

You use SwingUtilities to update the UI from any thread that is not the event dispatch thread. The EDT is the one that listeners get fired on, so you don't have to do that there.
The main method in an app is invoked in a thread that is not the EDT, so you should use it there to trigger code to load the UI.
The init method in an applet is (as far as I know) run in the EDT, so you shouldn't have to do that.
For the record, I don't think I've ever used invokeLater in the main method. It's generally not a problem until the UI is displayed.

Using swingworker and invokeLater together

Hi all�
Anyone knows if there is an appropiate way to use the worker thread through SwingWorker and invokeLater together?
It maybe sounds a bit weird but I have to launch a thread from EDT with invokeLater utility, otherwise i'd get a block state between EDT and my own thread. In other hand, I need to use SwingWorker utility for try to avoid the awful effect of loosing the visual desktop while transaction is proccesing.
Obviously, if i use SwingWorker and inside doInBackGorund method, launch my thread with invokeLater it doesnt make any sense since the worker do its work in differents threads...
I'd appreciate any help concerning this problem.

Hi Albert,
I believe that this code might help:
/*SwinWorker Clas*/
package swingworker;
import javax.swing.SwingUtilities;
* This is the 3rd version of SwingWorker (also known as
* SwingWorker 3), an abstract class that you subclass to
* perform GUI-related work in a dedicated thread. For
* instructions on using this class, see:
* http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
* Note that the API changed slightly in the 3rd version:
* You must now invoke start() on the SwingWorker after
* creating it.
public abstract class SwingWorker {
    private Object value; // see getValue(), setValue()
    private Thread thread;
     * Class to maintain reference to current worker thread
     * under separate synchronization control.
    private static class ThreadVar {
        private Thread thread;
        ThreadVar(Thread t) { thread = t; }
        synchronized Thread get() { return thread; }
        synchronized void clear() { thread = null; }
    private ThreadVar threadVar;
     * Get the value produced by the worker thread, or null if it
     * hasn't been constructed yet.
    protected synchronized Object getValue() {
        return value;
     * Set the value produced by worker thread
    private synchronized void setValue(Object x) {
        value = x;
     * Compute the value to be returned by the <code>get</code> method.
    public abstract Object construct();
     * Called on the event dispatching thread (not on the worker thread)
     * after the <code>construct</code> method has returned.
    public void finished() {
     * A new method that interrupts the worker thread. Call this method
     * to force the worker to stop what it's doing.
    public void interrupt() {
        Thread t = threadVar.get();
        if (t != null) {
            t.interrupt();
        threadVar.clear();
     * Return the value created by the <code>construct</code> method.
     * Returns null if either the constructing thread or the current
     * thread was interrupted before a value was produced.
     * @return the value created by the <code>construct</code> method
    public Object get() {
        while (true) {
            Thread t = threadVar.get();
            if (t == null) {
                return getValue();
            try {
                t.join();
            catch (InterruptedException e) {
                Thread.currentThread().interrupt(); // propagate
                return null;
     * Start a thread that will call the <code>construct</code> method
     * and then exit.
    public SwingWorker() {
        final Runnable doFinished = new Runnable() {
           public void run() { finished(); }
        Runnable doConstruct = new Runnable() {
            public void run() {
                try {
                    setValue(construct());
                finally {
                    threadVar.clear();
                SwingUtilities.invokeLater(doFinished);
        Thread t = new Thread(doConstruct);
        threadVar = new ThreadVar(t);
     * Start the worker thread.
    public void start() {
        Thread t = threadVar.get();
        if (t != null) {
            t.start();
/*TestSwingWorker*/
package swingworker;
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
public class MyApplication {
    public static void main(String[] argv) {
        final JFrame f = new JFrame("Test SwingWorker");
        /* Invoking start() on a SwingWorker causes a new Thread
         * to be created that will run the worker.construct()
         * method we've defined here. Calls to worker.get()
         * will wait until the construct() method has returned
         * a value (see below).
        final SwingWorker worker = new SwingWorker() {
            public Object construct() {
                return new ExpensiveDialogComponent();
        worker.start(); //new for SwingWorker 3
        /* The ActionListener below gets a component to display
         * in its message area from the worker, which constructs
         * the component in another thread. The call to worker.get()
         * will wait if the component is still being constructed.
        ActionListener showSwingWorkerDialog = new ActionListener() {
            public void actionPerformed(ActionEvent e) {
                JOptionPane.showMessageDialog(f, worker.get());
        JButton b = new JButton("Click here to show component constructed by SwingWorker");
        b.addActionListener(showSwingWorkerDialog);
        f.getContentPane().add(b);
        f.pack();
        f.show();
        //The following is safe because adding a listener is always safe.
        f.addWindowListener(new WindowAdapter() {
            public void windowClosing(WindowEvent e) {
                System.exit(0);
class ExpensiveDialogComponent extends JLabel {
    public ExpensiveDialogComponent() {
        super("This is the world's most expensive label.");
        try {
            Thread.sleep(10000); //sleep for 10 seconds
        } catch (InterruptedException e) {
}Hope it helps!

Relative order of invokeAndWait and invokeLater

Hi,
Lets say that I am using invokeLater under normal conditions, but wish to throttle the output with invokeLater every 1000 chars (approx.). The idea is that I get the speed of invokeLater normally, but allow the gui to catchup with the output generator on an infrequent basis. My question is whether the mix of invokeAndWait into the invokeLater sequence will be guaranteed to be in the proper order. There doesn't seem to be any discussion on Google.
Andy

-> My question is whether the mix of invokeAndWait into the
-> invokeLater sequence will be guaranteed to be in the proper order
Try it and let us know what happens.
Create a GUI with a text area.
Now create a loop that adds a single character to the text area where the append(...) method is wrapped in an invokeLater(...);
When the loop is finished you add another character to the text area using the invokeAndWait(...).
What do you think will happen? What actually happened?

InvokeLater() and invokeAndWait()

I'm somewhat confused about when to use these.
from http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html - it says "you must take extreme care that Swing components and models are created, modified, and queried only from the event-dispatching thread"
I also understand that these two methods are basically the same though invokeAndWait only returns once the run() has completed while invokeLater will return immediately.
So, when should I use these? and which one should I use?
If I'm creating the GUI initially, use the invokeAndWait()
If I'm updating/quering the GUI components, use invokeLater()
is this the correct way of thinking?

You only need to use these methods if you are updating your GUI from a Thread you have spawned. These methods insure the GUI udpate is performed from the event dispatcher thread as those methods put the GUI update in the event queue.
If you are already updating the GUI from the event dispatcher thread (i.e. from an ActionListener, MouseListener, etc) you don't need to use them.
For instance lets say you do an expensive database query (takes a noticeable amount of time to return results) when you press a button. If you just do the database query in the main thread the rest of your application will block while the db query is performed. So you would spawn a new thread with your db query in it. However, now lets say when the db query is over you want to update some status label to notify the user. You would put the label update in a Runnable object and pass that to invokeLater() which would put your runnable oject in the event queue which would eventually get executed by the event dispatcher thread.
Now the rest of your application is responsive while the db query is occuring. And the label will be updated in a thread safe way when the db query is done.
Generally invokeLater() is used, as invokeAndWait() blocks until the runnable object you add to the event queue is executed. This isn't generally desireable. More or less you can safely ignore invokeAndWait(), although keep it in mind for those rare occasions where its usage would be desireable.
Here a very generic example:
public void actionPerformed(ActionEvent e) {
      //Button has been pressed lets query the db in a thread
      new Thread() {
            public void run() {
                //Hit the DB
                Runnable changeLabel = new Runnable() {
                    public void run() {
                        label.setText("tell user db query is done");
                //Put the changing of the label in the event queue
                EventQueue.invokeLater(changeLabel);
        }.start();
}

InvokeLater() and invokeAndWait(): concerns over synchronization

I've been reading up on the methods invokeLater(Runnable) and invokeAndWait(Runnable) and I've understood this much: the difference is in the synchronization of the new thread with the main (or current) one. I somewhat familiar with what synchronization means (i.e. it's a way of guaranteeing that changes made to shared resources are seen by all threads as soon as they are made).
My question is: does a call to invokeAndWait() mean that I don't have to worry about synchronizing methods and code?

gib65 wrote:
My question is: does a call to invokeAndWait() mean that I don't have to worry about synchronizing methods and code?No. Both the invoke methods just push off code to be executed in the event thread. That might mean that you don't need synchronization, but only if the synchronization was needed because you had the event thread and another thread accessing same resources.
The difference is that invokeLater doesn't stop the execution of the current thread, while invokeAndWait stops the current thread until the task has been run on the event thread.

InvokeLater

Similar Messages

Maybe you are looking for