Le 14/10/2009 13:11, Anthony Petrov a écrit :
While I'm still waiting for some answers to the questions outlined
below, I also just recalled another issue.
About a year ago or so we developed a fix to replace the components
array with a collection in the Container class. The initial version of
the fix included synchronized (getTreeLock()) sections in such methods
like countComponent(), getComponent(int), and some other. I recall we
indeed faced dead-locks back then, and decided that a developer must
hold the lock when calling these methods, so that we could avoid
acquiring the lock ourselves.
How does that decision correspond to the current proposal of forcibly
getting the lock in the preferredSize(), paramString(), some Swing
methods, and others? Wouldn't that be safer to shift the
responsibility of holding the lock to the user's code instead (as just
assumed currently, in fact)?
Anthony,
did you try top use a CopyOnWriteArrayList as Collection ?
It's a thread safe collection which duplicate the array at each mutation.
my two cents.
--
best regards,
Anthony
Rémi
