<Swing Dev> Regarding the fix for 6852592 (revalidate() must be smarter)

Anthony Petrov Anthony.Petrov at Sun.COM
Tue Aug 11 16:08:01 UTC 2009


Hello dear Swing and AWT teams, hi Chris,

Lately there were no news on the fix we've been eagerly discussing in 
the past several weeks. And I'm writing this to clarify the current 
state of the issue.

Unfortunately we indeed found incompatibilities with our solution: a 
Swing regression test failed. In a nutshell, the test adds components in 
a container within its root pane, and then displays its top-level 
container which (indirectly) contains the root pane. However, the root 
pane itself had already been correctly sized *before* the components 
were added. Therefore the direct ancestor of the root pane is valid 
before the component are added.

In the past the test expected that the validate() invoked from the 
Window.show() method would lay out the components in all containers 
(including the one within the root pane).

After the fix the invalidate() method stops propagating the invalidation 
request (caused by adding the components) behind the root pane (since 
it's a validate root), therefore leaving the direct container of the 
root pane valid. Obviously, the validate() request from the 
Window.show() will pass by the valid container, thus leaving the 
components within the root pane not-laid-out.

 From AWT perspective, the operation of adding a component to a 
component hierarchy must be followed by a validation request within the 
validate root of the hierarchy. However, this test, relaying on the 
previous behavior, does not make such a request, and therefore fails.

Possible solutions include:

1. Adding a call to revalidate() method immediately after the components 
have been added to the container in the test code. However, from Swing 
perspective this looks like a backward incompatibility.

2. Overriding the JComponent.addImpl() method and putting the call to 
revalidate() there. This, however, may introduce some performance 
regression.

Since subsequent evaluation of the issue naturally lays in the Swing 
area, the AWT team decided to redispatch the bug to the Swing team for 
further investigation. Please stay tuned for their resolution.

In the meantime the AWT team is going to update the specification of the 
Component and Container classes in order to:

1. Indicate the requirement introduced by the HW/LW Mixing feature 
(notably, the requirement of keeping the whole component hierarchy valid 
if the hw/lw mixing takes place).

2. Explicitly mark all the methods that invalidate the component 
hierarchy so that developers know when exactly they need to validate 
their component hierarchies.

The CR for this update is: 6868255 (it isn't available on the 
http://bugs.sun.com for some unknown reason).

I want to thank everyone who participated in the discussion, especially 
Chris Deckers for rising the issue and making reasonable proposals. I 
believe that a justified resolution for the issue will be concluded someday.

--
best regards,
Anthony



More information about the swing-dev mailing list