File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

When To Use InvokeLater()

 
Isaac Hewitt
Ranch Hand
Posts: 191
Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 20372
44
Chrome Eclipse IDE Java Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I prefer to execute all code that interacts with the user interface on the EDT. When in doubt go the safe way.
 
Manuel Petermann
Ranch Hand
Posts: 177
Hibernate Linux Python
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Pie
Posts: 47250
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2475
8
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5115
11
Java Netbeans IDE Opera
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 177
Hibernate Linux Python
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 47250
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 191
Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 177
Hibernate Linux Python
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 47250
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5115
11
Java Netbeans IDE Opera
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 47250
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 177
Hibernate Linux Python
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic