<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