When To Use InvokeLater()

[Isaac Hewitt]

I am programming a desktop app in Java 7 update 13 with netBeans. I am aware of the fact that GUI methods such as component.setText() should be used with invokeLater(), as well as component.setEnabled(), but I am unsure about other things such as setting the cursor etc. Is there a list somewhere for its usage invokeLater() ? thanks.

[Rob Spoor]

I prefer to execute all code that interacts with the user interface on the EDT. When in doubt go the safe way.

[Manuel Petermann]

As long as you stay on the event dispatch thread you don't have to call invokeLater.
You just have to call invokeLater or invokeAndWait if you are calling from another thread.

I doubt that there is a list of all non thradsafe methods in java anywhere so I guess its safe
to assume a method/class is not threadsafe if not written in the documentation.

Just for future reference, there is no component.setText. Maybe you meant a JLabel but thats besides the point.
However it is not necessary and actually very bad to spawn a new Runnable for every single call to those methods.

[Campbell Ritchie]

Manuel Petermann wrote: . . .

I doubt that there is a list of all non thradsafe methods in java anywhere so I guess its safe to assume a method/class is not threadsafe if not written in the documentation.
. . .

Very sensible assumption. It does actually say in the documentation for every Swing class I can remember that

Warning: Swing is not thread safe. For more information see Swing's Threading Policy.

You should take that as a hint to assume that every method is not‑thread‑safe.

[Rob Camick]

I am aware of the fact that GUI methods such as component.setText() should be used with invokeLater(), as well as component.setEnabled(),

The general rule is that code that updates the GUI needs to be executed on the Event Dispatch Thread (EDT).

So, for example, code that executes in an Event Listener is automatically invoked on the EDT so there is no need for you use invokeLater() in this case.

[Darryl Burke]

Manuel Petermann wrote:As long as you stay on the event dispatch thread you don't have to call invokeLater.

I beg to differ. Execution of some code for custom behavior needs to be deferred until after code for the default behavior has completed.

Manuel Petermann wrote:You just have to call invokeLater or invokeAndWait if you are calling from another thread.

I doubt that there is a list of all non thradsafe methods in java anywhere so I guess its safe
to assume a method/class is not threadsafe if not written in the documentation.

... but consult the API for Java 7. Several methods that are documented as being thread safe up to Java 6 are actually not, and the documentation has been corrected in Java 7.

Manuel Petermann wrote:However it is not necessary and actually very bad to spawn a new Runnable for every single call to those methods.

Why exactly do you consider it 'very bad'?

[Manuel Petermann]

Darryl Burke wrote:

Manuel Petermann wrote:As long as you stay on the event dispatch thread you don't have to call invokeLater.

I beg to differ. Execution of some code for custom behavior needs to be deferred until after code for the default behavior has completed.

Thats why I said "you don't have to". I didn't mean "you mustn't".

Darryl Burke wrote:

Manuel Petermann wrote:You just have to call invokeLater or invokeAndWait if you are calling from another thread.

I doubt that there is a list of all non thradsafe methods in java anywhere so I guess its safe
to assume a method/class is not threadsafe if not written in the documentation.

... but consult the API for Java 7. Several methods that are documented as being thread safe up to Java 6 are actually not, and the documentation has been corrected in Java 7.

I consider that a bug or error from oracle. You have to rely on something.

Darryl Burke wrote:

Manuel Petermann wrote:However it is not necessary and actually very bad to spawn a new Runnable for every single call to those methods.

Why exactly do you consider it 'very bad'?

1. If you have many calls to the edt and you wrap all of them in a different Runnable you need to create those Runnables. Overhead which is usually easy to get rid of.
2. If you are updating one component in rapid succession you may end up in overwriting changes before they are getting visible.

[Campbell Ritchie]

Manuel Petermann wrote: . . .
2. If you are updating one component in rapid succession you may end up in overwriting changes before they are getting visible.

That sounds like a race condition to me. If you only use one thread, the second method call cannot start until the first has finished.

[Isaac Hewitt]

Thank you to all of you who responded.

I have read your responses and it is alot of food for thought.

I do find that my GUI in several instances remains highly responsive if I use InvokeLater. Of course it is very subtle, but I think (perhaps I am wrong) that performance can degrade over time if one does not use this method in the right places.

I just was not too sure about things such as setting the cursor.

I use it on setting scrollbar positions, text, enabling/ disabling components, requesting focus etc, anything really that has to do with Swing.

       if(this.scrollPane.getVerticalScrollBar().getValue() != 0) {
                
               SwingUtilities.invokeLater(new Runnable() {
                     @Override
                     public void run() {  
                        FilmTableFrame.this.scrollPane.getVerticalScrollBar().setValue(0);
                     }
                });
            }

Thank you once again to all of you.

[Manuel Petermann]

Campbell Ritchie wrote:

Manuel Petermann wrote: . . .
2. If you are updating one component in rapid succession you may end up in overwriting changes before they are getting visible.

That sounds like a race condition to me. If you only use one thread, the second method call cannot start until the first has finished.

I meant it more like for example flooding the edt with updates to a JLabel's setText method and ending up seeing a blur of text.

[Campbell Ritchie]

Yes, I see what you mean. You may have to allow anything up to 25ms for a GUI to repaint itself, so multiple alterations in a thread may be missed out.

[Darryl Burke]

If you need to be able to observe multiple successive updates, you should be using a Timer; you cannot rely on the time it takes to repaint, as this is largely dependent on the hardware configuration. It's documented that calling repaint()

defers the actual painting and can collapse redundant requests into a single paint call.

Since JLabel's setText(...) internally calls repaint() and not paintImmediately(...) this shouldn't be possible:

flooding the edt with updates to a JLabel's setText method and ending up seeing a blur of text.

[Campbell Ritchie]

Darryl Burke wrote: . . . this shouldn't be possible: . . .

Presumably what is happening is that it is repainting several times a second, enough to be visible but too fast for anybody to read the text.

[Manuel Petermann]

Exactly. However, this problem is not necessarily bound to text. That was just an example.
The SwingWorker uses a Timer to prevent that from happening if you are calling the publish or setProgress method.