<Swing Dev> Review request: 6852592 (revalidate() must be smarter)
Alexander Potochkin
Alexander.Potochkin at Sun.COM
Wed Jul 15 15:54:34 UTC 2009
Hello Anthony
While the fix itself does what we need,
its implementation is quite confusing
Component.invalidate() calls invalidImpl()
and JComponent.invalidate()
also calls invalidImpl() for validate roots and otherwise
calls super.invalidte()
I think checking isValidatRoot() on AWT side
will save lots of lines of code
Here is the existing code from the Component class
if (Component.isInstanceOf(this, "javax.swing.JComponent")) {
if (((javax.swing.JComponent) this).isOpaque()) {
states.add(AccessibleState.OPAQUE);
}
}
Can we do the same for isValidatRoot()?
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
More information about the swing-dev
mailing list