let's play TDD, tackles closures in java

[Jim Mayer]

Swing requires that methods be invoked on the EDT unless they are explicitly
documented as being thread safe (e.g., "repaint").

Events (e.g., MouseEvent, etc.) that come from the system are delivered on
the EDT.

Because of these rules, worker (non-EDT) threads trend to make heavy use of
EventQueue.InvokeLater to perform Swing operations on the EDT.

Listeners in Swing (mostly PropertyChangeListener) follow the beans model
and are executed in the thread that caused the listener to be fired.  In the
general Java bean case, this is a recipe for deadlocks IMHO, but if one
wants to support things like VetoableChangeListener it's hard to see what
else to do. In the case of Swing, I believe the rules imply that all Swing
related listeners are invoked on the EDT.

Regarding this discussion, I think that, unless the threading behavior is
very well defined, that it is unsafe to assume anything about the context
(thread, locks held, etc.) in which a listener is invoked.  Listeners,
however, are a very specific form of callback, and, personally, I believe
that assuming that all closures can be invoked from multiple threads would
be going too far).  There are lots of control constructs (e.g., folding with
a non-associative operator) where sequential evaluation is required
semantically.

-- Jim
On Dec 20, 2010 8:03 AM, "Tom Hawtin" <tom.hawtin at oracle.com> wrote: