swing not thread-safe

[ap]

Sun makes the statement:

"Once a Swing component has been realized, all code that might affect
or depend on the state of that component should be executed in the
event-dispatching thread."

Following this recommandation may cause a lot of additional code,
especially when dealing with GUI events, that trigger time consuming
tasks. I use to write event-driven programms that works like a state
machine: the listener only changes states and NOTHING ELSE. A special
thread contains a state event loop does all the task. It also updates
Swing components. Is this safe enough? (I never had a problem.)

[Thomas Hawtin]

ap wrote:
> Sun makes the statement:
>
> "Once a Swing component has been realized, all code that might affect
> or depend on the state of that component should be executed in the
> event-dispatching thread."

The current position is that access to (including construction of) Swing
components should be done on the EDT, even before they are realised.

> machine: the listener only changes states and NOTHING ELSE. A special
> thread contains a state event loop does all the task. It also updates
> Swing components. Is this safe enough? (I never had a problem.)

It is not safe to update Swing components off the EDT, except where
explicitly noted.

You might not notice any problems, but that does not mean everybody else
will be as lucky. For instance, when upgrading to Java 1.5 I found a
Swing-related deadlock in jEdit. Then same thing happened when I
upgraded to 1.6.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/