wood burning stoves 2.0*
The moose likes Swing / AWT / SWT and the fly likes When To Use InvokeLater() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "When To Use InvokeLater()" Watch "When To Use InvokeLater()" New topic
Author

When To Use InvokeLater()

Isaac Hewitt
Ranch Hand

Joined: Jul 24, 2006
Posts: 190

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
Sheriff

Joined: Oct 27, 2005
Posts: 19651
    
  18

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


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Manuel Petermann
Ranch Hand

Joined: Jul 19, 2011
Posts: 175

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.


Please correct my English.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37970
    
  22
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
Ranch Hand

Joined: Jun 13, 2009
Posts: 2153
    
    7
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
Bartender

Joined: May 03, 2008
Posts: 4523
    
    5

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'?


luck, db
There are no new questions, but there may be new answers.
Manuel Petermann
Ranch Hand

Joined: Jul 19, 2011
Posts: 175

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
Sheriff

Joined: Oct 13, 2005
Posts: 37970
    
  22
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
Ranch Hand

Joined: Jul 24, 2006
Posts: 190

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.




Thank you once again to all of you.
Manuel Petermann
Ranch Hand

Joined: Jul 19, 2011
Posts: 175

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
Sheriff

Joined: Oct 13, 2005
Posts: 37970
    
  22
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
Bartender

Joined: May 03, 2008
Posts: 4523
    
    5

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
Sheriff

Joined: Oct 13, 2005
Posts: 37970
    
  22
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
Ranch Hand

Joined: Jul 19, 2011
Posts: 175

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.
 
Don't get me started about those stupid light bulbs.
 
subject: When To Use InvokeLater()
 
Similar Threads
Null pointer exception.....
Stretch the image size.
FBNX: Gui and Threads, asynchronous Swing action execution and GUI updating.
LostFocus and SwingUtilities.invokeLater()
How to handle Modal Frame and Runnable thread simultaneously