SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
Please correct my English.
Very sensible assumption. It does actually say in the documentation for every Swing class I can remember thatManuel 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.
. . .
You should take that as a hint to assume that every method is not‑thread‑safe.Warning: Swing is not thread safe. For more information see Swing's Threading Policy.
I am aware of the fact that GUI methods such as component.setText() should be used with invokeLater(), as well as component.setEnabled(),
Manuel Petermann wrote:As long as you stay on the event dispatch thread you don't have to call invokeLater.
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.
Manuel Petermann wrote:However it is not necessary and actually very bad to spawn a new Runnable for every single call to those methods.
luck, db
There are no new questions, but there may be new answers.
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.
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.
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'?
Please correct my English.
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.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.
Campbell Ritchie wrote:
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.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.
Please correct my English.
defers the actual painting and can collapse redundant requests into a single paint call.
flooding the edt with updates to a JLabel's setText method and ending up seeing a blur of text.
luck, db
There are no new questions, but there may be new answers.
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.Darryl Burke wrote: . . . this shouldn't be possible: . . .
Please correct my English.
Make yourself as serene as a flower, as a tree. And on wednesdays, as serene as this tiny ad:
Clean our rivers and oceans from home
https://www.kickstarter.com/projects/paulwheaton/willow-feeders
|