RFR: 8290844: Add Skin.install() method [v2]

[Kevin Rushforth]

On Thu, 11 Aug 2022 13:17:43 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> > The new API is backwards compatible with the existing code, the customer-developed skins can remain unchanged (thanks to default implementation).
> 
> hmm ... probably I'm missing something but I don't see how that would be the case for the subset of core skins that have to be refactored and moved their installation into the install() method. Typically, custom skins do their own stuff on top of what super did at the end of the constructor, assuming that everything is fully installed. Depending on what exactly will be moved into install, their behavior will be broken after the change.

Maybe. As you say, it depends on what is moved from the constructor into `install()`.

> Examples:

[snip]

How common do you think this sort of thing is in practice? This seems like a case of the subclass "peeking" at the implementation of its superclass, and then coding in such a way as to rely on that implementation. This does suggest that we ought to take a cautious approach, only overriding and implementing `Skin::install` for those built-in controls where it is needed to fix bugs. It also suggests that this possible incompatibility ought to be highlighted in a release note (in addition to updating the CSR, which Andy has indicated that he will do).

-------------

PR: https://git.openjdk.org/jfx/pull/845