JDK-6852592 : invalidate() must be smarter
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-06-18
  • Updated: 2017-05-16
  • Resolved: 2009-11-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b77Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
The HW/LW Mixing feature depends on having the whole component hierarchy valid. However Swing's revalidate() methods stops validation on the nearest validateRoot which may easily leave the toplevel window invalid. That in turn leads to the mixing feature to work incorrectly - we do not recalculate shapes for invalid containers since their children may have invalid bounds.

One could suggest the user application to call the validate() on the top-level, but this is not the best solution as well. See the following justification:

*******************************************************************************
> You aren't the only one. The hw/lw mixing is a new feature, and it also
> brings some new requirements to work correctly. The main requirement is that
> the whole component hierarchy must be valid. Otherwise the mixing may not
> correctly do its job. So I suggest you to replace the panel.revalidate()
> call with the <the-toplevel-window>.validate() call instead. This will fix
> the issue.

Wouldn't it be better if revalidate was validating the full hierarchy
when a sub component is heavyweight? It could do its normal job and
post a runnable to validate the window ancestor in such a case.
Otherwise every time one does a revalidate, they have to know what
they embed to perform the right validation. This is not very possible
when you don't know what you embed (library integration for example).
As a matter of fact, I don't know myself if the component hierarchy I
am adding contains a native component: my program shows native stuff
and some non native stuff depending on the selection on the tree that
is located on the left side of the split pane.
*******************************************************************************

Since the AWT code always knows whether we do mixing or not, the Swing's revalidate() method may have the following logic:

1. If the mixing is taking place, it can find the toplevel ancestor of the container and call its validate() method.
2. Otherwise it must fall back to the current mechanism involving the validateRoots.

To identify if the mixing is active, one could introduce the sun.awt.AWTAccessor.ComponentAccessor.isMixingNeeded() method that would call the corresponding private method in the java.awt.Component class.

Comments
EVALUATION Reviewed at http://mail.openjdk.java.net/pipermail/awt-dev/2009-September/000934.html
25-09-2009

EVALUATION The requirements introduced by the HW/LW Mixing feature will be specified in the javadoc of the java.awt.Component class with the CR 6868255. Swing applications that use the HW/LW Mixing feature should satisfy the requirements in order to operate correctly (either with automatic support provided by the Swing library, or by means of the application code).
04-08-2009

EVALUATION Based on the discussion on the awt-dev@ and ###@###.### mailing lists it is decided to override the JComponent.invalidate() method. The AWT's Component.invalidate() methods usually traverses all the ancestors of the component the method is invoked on (up to where the parent is null), and invalidates all these ancestors. Instead the overridden version of this method in the JComponent class will stop on a nearest "validate root" ancestor (see JComponent.isValidateRoot()), or a null parent - whichever comes first.
15-07-2009