JDK-7037453 : Clarify specification for Component.revalidate() and other validity- and mixing-related methods
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2011-04-18
  • Updated: 2021-07-13
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-7036669 - Simplify revalidating component hierarchy with multiple validate roots
Description
The specification for Component.revalidate() (introduced with 7036669), as well as that of the invalidate() method is slightly unclear as to whether the invalidation stops on the component itself if the component is a validate root, or goes higher in the component hierarchy to locate a validate root for this component. The actual implementation of the method is that it goes upper in the hierarchy to find a validate root. This behavior is considered correct.

Also, we need to mention the new revalidate() method in the specifications of the rest of validity-related methods (invalidate(), validate(), isValidateRoot(), Component class spec, etc.)

Besides, it makes sense to generally revise the specification of the HW/LW Mixing feature to demonstrate the best practices of (re)validation of component hierarchies after making changes to the layout-related properties of components.
Comments
This issue is not a bug, but an enhancement. It only affects the documentation and suggests to provide some minor (but nonetheless, important) clarifications. Due to resources shortage, I retarget this issue to JDK 9. There's no escalations/external requests or any direct dependencies associated with it, but it still should be P3 to make sure we find time to fix it in JDK 9.
23-08-2013
EVALUATION Per description.
18-04-2011