JDK-8260364 : Doc error: Skinnable methods over-specified to Control
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: openjfx15
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2021-01-25
  • Updated: 2022-11-03
  • Resolved: 2022-11-03
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
tbdFixed
Related Reports
Relates :  
Relates :  
Description
Basically, any collaborator in the scenegraph could implement skinnable, not only controls. Actually, there is at least one (PopupControl) that isn't. 

So all methods in the interface Skinnable should specify _Skinnable_ (vs _Control_ as they do now)

for instance:

    /**
     * Sets the skin that will render this {@link Control}
     * @param value the skin value for this control
     */
    public void setSkin(Skin<?> value);

should be changed to (modulo doc conventions, not entirely certain about lower/upper casing nor self-references?)

    /**
     * Sets the skin that will render this skinnable.
     * @param value the skin value for this skinnable
     */
    public void setSkin(Skin<?> value);

Apart from that, the description of Skinnable needs some love - it's an implementation note, not very expressive and stating the obvious:

    The Skinnable interface is implemented by the Control class, and therefore is implemented by all Control implementations.
 
Should be changed to describe _what_ it is for, maybe somehow the inverse of Skin: 

   A Skinnable delegates its visual representation to its {@link Skin}. ...

Without updating the description, the change might be small enough to go into JDK-8252389 (but as discussed its PR: if we want to change the description as well, we'll need a separate issue anyway)
Comments
addressed in JDK-8290844
03-11-2022

I am trying to address these concerns in JDK-8290844, [~fastegal]
12-08-2022