[concurrency-interest] Confused about Component.getTreeLock()

Gregg Wonderly gregg at cytetech.com
Tue Mar 6 16:02:04 EST 2007



Thomas Hawtin wrote:
> Gregg Wonderly wrote:
> 
>>
>> The standing statement from the swing development team WAS that you 
>> should never touch a "realized" component without using the event 
>> dispatch thread.  As of JDK1.5, they've ammended this statement to 
>> demand that anything which can cause a component to be realized must 
>> be in the event dispatch thread.  This includes things like 
>> Window.pack() and Window.setVisible(true).
> 
> 
> For Swing components. In fact other stuff, like JTextField via 
> documents, can use invokeLater internally and therefore screw up. So now 
> it's do everything on the EDT (with a few exceptions). It turns out that 
> the explicit multithreading capabilities of the Swing text doesn't 
> actually work or indeed make any sense.

In that case, the component (the JTextField) is realized, so based on the old 
verbage, you should "know" to use the EDT.  There are a number of things that 
use InvokeLater to multitask the GUI better.  JComponent.revalidate() is one 
such thing.  If you've ever used a resizing JPanel inside of JScrollPane, you 
know that you have to be careful to use InvokeLater for anything that you do 
after a JPanel.setPreferredSize() (such as repaint or other things that use the 
new size).  If you do them in the EDT, and that EDT leg has invoked 
setPreferredSize(), then you won't see the size changes that setPreferredSize() 
effected.

At the end of the day, it's a tough balancing act.  You want to allow the 
application and the EDT to proceed independently, yet to be synchronized in how 
they interact with each other.

Gregg Wonderly


More information about the Concurrency-interest mailing list