I'll try to change the behavior locally and see how much of JavaFX breaks as a result. I don't think that a lot of code relies on the property being in a valid state while in fact it isn't when attaching a listener. I could be wrong...
On Sun, Aug 29, 2021 at 6:23 PM John Hendrikx <hj...@xs4all.nl> wrote: > > > On 29/08/2021 01:34, Nir Lisker wrote: > >> > >> This actually isn't an issue because adding an invalidation listener > >> revalidates the property as well (I'm not sure why, but I noticed this > >> before while working on fluent bindings). > >> > > > > There is an open issue on this: > > https://bugs.openjdk.java.net/browse/JDK-8208750. > > > > This is also the cause for the When binding evaluating the 'false' branch > > unneededly. Maybe this is a good time to have a look if this can be > > changed. The problem is finding how much code relies on this unspecified > > behavior. > > Yeah, I fear that changing this now may introduce subtle problems, both > in JavaFX itself and quite some user and library code. > > Invalidation and ChangeListeners are quite often chosen without much > thought in user code, where the consideration is more whether you want > the old value or whether you want to avoid boxing. Such code just calls > "get" to make it similar to a ChangeListener, even though there still is > a subtle difference which, in the current implementation, is hidden. > > Current code using the invalidation + get variant would break if the > property in question was already invalid at the time of registration, as > then no further invalidations would be received in the absence of > something external revalidating that property. Once it is revalidated > once, the code would function as "intended", which further hides the > problem (ie, problem only occurs once or only at startup or something). > > If fixing this proves too risky, we probably should document > Bindings#when with a warning and perhaps offer an alternative (fluent > bindings or a new Bindings method that just takes a mapping function :)). > > --John > > > > > >
