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
