let's play TDD, tackles closures in java

[Mikael Grev]

Swing is for all intents an purpises single threaded. Only the EDT may call any Swing methods or constructors. There are exceptions to this rule but that is documented for every single case. Nasty things happens if you break this extremely important rule.

I don't know of any multi threaded GUI toolkit in use but some has better handling of internal dispatching than Swing does which is a different thing but make the GUI look less frozen than for Swing for long running tasks on the GUI thread. 



On 20 dec 2010, at 14:01, Tom Hawtin <tom.hawtin at oracle.com> wrote:

> On 20/12/2010 10:49, Brian Goetz wrote:
> 
>> So, in what thread is the closure going to get executed?  Listeners are generally fired in the EDT (in correctly written programs).  Which means that this code example has a data race, and is therefore broken.
> 
> A bit off topic, but: Are you sure? Isn't "generally" a problem?
> 
> I am not entirely sure what a correctly written Swing program would look 
> like.
> 
> "Notification is done on the thread that produced the mutation [...]" in 
> AbstractDocument doesn't sound like the EDT.
> 
> Swing text attempts to be thread-safe but is all over the place. How do 
> you do something as complicated as appending text through the Document 
> interface? Swing text is thread-hostile.
> 
> Testing a known thread-agnostic use of TableModel is sensible. (Top tip: 
> Put a layer of indirection between the body of your code and code that 
> uses mutable statics, such as 
> java.awt.EventQueue.invokeLater/isDispatchThread.)
> 
> Tom