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

[Alexander Potochkin]

Hello Anthony

> Hi Alex,
> 
> On 7/27/2009 8:41 PM Alexander Potochkin wrote:
>> By the way, when isValidateRoot() method will be brought up to 
>> Component, I expect the cast to be removed
>>
>> if ((c instanceof JComponent) && (((JComponent)c).isValidateRoot()))
> 
> A component cannot be a validate root by logical reasons: it has nothing 
> to lay out inside itselft, and therefore the state of 
> validity/invalidity is not relevant to a component. Moreover, a 
> component does not have children, thus it can't be a 'root' at all. 
> Therefore I expect the isValidateRoot() method to stay in the Container 
> class for quite a long time.

It is actually doesn't matter much

Component is the base class for the whole library
and it is ok for it to have some methods
that only make sense it its subclasses

Component.getBaseline() is a good example

It is so inconvenient to type

if ( (c instanceof JComponent) &&
(((JComponent) c).getBaseline()== somethinng))

so AWT team kindly agreed to brought this method up to the Component
even if it makes no sense for AWT components

isValidateRoot() should be checked from different places both on Swing 
and AWT sides, so it really make sense to add it to the Component class

> 
> Regarding the mentioned condition, it needs to be changed as 
> s/JComponent/Container/, and so needs to be changed the code around it 
> to make sure the 'c' is used as a normal AWT container w/o any special 
> treatment of it as an instance of the JComponent.
> 
> 
>> But, when addInvalidComponent() finds no vaidateRoot,
>> it immediately returns, and this behavior will be affected
>>
>> I see no strong reasons to make Windows and Applets to be validate 
>> roots, just because it won't give us any benefits and may break the 
>> existing code
> 
> Besides, please consider a situation when one uses a few Swing 
> components in an AWT application (which is rare, but not impossible). 
> While this is not an 'officially supported' kind of mixing, I don't see 
> reasons why it shouldn't generally work. Now suppose one of the Swing 
> components is a popup (like a context menu, or a combo box, whatever). 
> After displaying the popup, the Swing code is expected to call the 
> revalidate() method which works perfectly in case of a Swing 
> application. However, since AWT applications normally don't have 
> validate roots, the addInvalidComponent() will fail to validate the 
> hierarchy, and we may observe some weird stuff (we do in fact: see the 
> bug 6862117). That's why I think it is OK to make the Window and the 
> Applet classes validate roots. 
 > With the changes to the
 > addInvalidComponent() described above, everything should work just
 > fine.

Using Swing components in AWT applications is incorrect,
not supported and I doubt it will ever be

Here is the JComponent's javadoc:

  * To use a component that inherits from <code>JComponent</code>,
  * you must place the component in a containment hierarchy
  * whose root is a top-level Swing container.
  * Top-level Swing containers --
  * such as <code>JFrame</code>, <code>JDialog</code>,
  * and <code>JApplet</code> --

So the described scenario is not really relevant

> Could you please elaborate on possible situations that could break after 
> making the Window/Applet the validate root?
> 

Let me describe the "best fix"

1) Bring isValidateRoot() up to the Component class
2) Make it return false
3) Leave all other stuff intact

This proposal is 100% safe and does what we need

Would you agree?

Thanks
alexp

> -- 
> best regards,
> Anthony