One more concern that comes to my mind is that the logic stated in the
Swing's method specification is going to be implemented on the AWT's
side, which I don't like much. So definitely we need more opinions on
this proposal.
--
best regards,
Anthony
On 7/15/2009 8:16 PM Alexander Potochkin wrote:
Hello Anthony
Can we do the same for isValidatRoot()?
Yes, that is a smaller solution (in terms of the code size),
smaller fix is less error-prone
and gives better maintainable code for future changes
though I prefer to minimize calling Swing stuff from AWT code. What do
others think?
let's wait for the rest of the team
Thanks
alexp
--
best regards,
Anthony
Thanks
alexp
Hello Swing and AWT teams,
This is a fix for the problem discussed recently (see the thread
"Lw/Hw mixing vs revalidate()/validate()/invalidate()"). The webrev:
http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.0/
Please review.
A couple of notes:
1. We need to get a CCC approval for the API specification changes.
This will take some time.
2. The Container.invalidate() previously had a block of code that
was executed w/o grabbing the TreeLock (a call to the
LayoutManager2.invalidateLayout())). Now the code is moved to the
invalidateImpl() which is always invoked under the TreeLock. This
doesn't seem to be a problem: actually only the initial call to the
Container.invalidate() ran the code off the lock. All subsequent
recursive calls to this method did in fact happen under the lock.
Therefore I assume that this change is OK.
--
best regards,
Anthony
