On Thu, 11 Aug 2022 13:17:43 GMT, Jeanette Winzenburg <[email protected]> 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
