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

[Anthony Petrov]

Hi Alex,

On 07/28/2009 10:31 PM, Alexander Potochkin wrote:
>>> As for the second question about making Window/Applet validate roots,
>>> I just don't see any practical benefits of this
>>>
>>> Could you please give more details why it is worth doing?
>>
>> As to the Applet class, there's a valid justification: the user does 
>> not have a direct access to the underlying embedded frame which 
>> therefore might be left invalid forever. Please see [1] for the 
>> detailed description.
> 
> If you absolutely need at least one validate root in the hierarchy,

This is not required. The requirement is to keep the whole hierarchy 
valid. We can achieve that either using validate roots or calling 
validate() on the top-level component. Since applets do not have 
"official" access to/knowledge about their top-level component (the 
embedded frame), we have to workaround that making the Applet a validate 
root.


> and know how to correctly rewrite the messy code in RepaintManager and 
> JViewport, I am fine with that

Hm, what kind of code might work wrong in that classes when the Window 
and the Applet become validate roots? I don't see anything suspicious 
there. In the mentioned snippets looking for a top-level component is 
only used to verify that the whole hierarchy is contained within a 
top-level. Since the search starts exactly from the previously found 
validate root, the code must work perfectly even if there's no validate 
roots between a component and the top-level (i.e. when there's no a 
RootPane at least, which is unlikely for a Swing top-level, ain't it?) 
But as I said, even in that fantastic case everything seems to work OK.


>> Regarding the Window: Artem proposed that at [2]. I didn't come up 
>> with any failing scenario, so I considered this change harmless and 
>> applied it. IMO, it isn't technically needed, but is conceptually 
>> correct. Perhaps Artem might comment on that?

And here comes the technical justification to make the Window a validate 
root. A component in a hierarchy can have two kinds of ancestors: a 
container and an owner. The first one is the physical container as seen 
on the screen (say, a Panel that a Button lays on). The latter is a 
component that is kind of responsible for and/or dependent on the owned 
component (like when the owned component must block its owner in some 
cases, for instance). A perfect example is an owned modal Dialog. Dialog 
does not have a container ancestor, but may indeed have an owner.

Unfortunately the API in AWT does not make any difference between these 
kinds of ancestor: the Component.getParent() is used for both. And 
unfortunately we can't change that now due to backward-compatibility 
issues (that's why it is very important to architect APIs carefully from 
the start.)

That said, the invalidate() method may easily jump to the owner of a 
dialog (or a window) while invalidating the hierarchy of the owned 
window - which is absolutely incorrect. To make sure this never happens, 
we need to stop invalidating on top-level components, hence the need to 
make the Window a validate root.

Sounds reasonable?

--
best regards,
Anthony