[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Re-examine the risks of JDK-8264770 breaking third party libraries and applications.
From:       Nir Lisker <nlisker () gmail ! com>
Date:       2021-08-29 19:50:45
Message-ID: CA+0ynh-chs3gpw4uS0=1aK70AdHVdYnJZeaDsEZqQ2i_6XgtMQ () mail ! gmail ! com
[Download RAW message or body]

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 <hjohn@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
>
>
>
>
>
>
[prev in list] [next in list] [prev in thread] [next in thread]