<Swing Dev> Review request: 6852592 (revalidate() must be smarter)

[Alexander Potochkin]

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