Re-examine the risks of JDK-8264770 breaking third party libraries and applications.

[John Hendrikx]

Sorry, I swapped the properties around. Here is another attempt:

The bindings added do not validate the properties anymore as it is an 
invalidation listener now instead of a change listener. This doesn't 
matter for property2 as its getValue is called which will force its 
revalidation, but for property1 this is not the case.

If property1 was already in an invalid state when the binding was made 
(because someone changed its value but nobody was listening) then 
calling setValue again will not revalidate it. The invalidation listener 
added at this point also will not receive anything until something 
revalidates the property, so any changes made after the bidirectional 
binding is established to this property will not be copied to the other 
property (although the other way around will work).

--John

On 28/08/2021 22:14, John Hendrikx wrote:
> Was it taken into account that when you register an invalidation listener:
>
>         property1.setValue(property2.getValue());
>         property1.addListener(binding);
>         property2.addListener(binding);
>
> ... that if property2 is currently invalid it will not send any further
> invalidations?
>
> Property1 is revalidated (because of the getValue call), but property2
> (if already invalid) will not become valid with that setValue call.
>
> Before when they were ChangeListeners, both properties became valid
> after a bidirectional binding, now that doesn't seem to be the case
> anymore.
>
> --John
>
>
> On 26/08/2021 09:29, Frederic Thevenet wrote:
>> Hi,
>>
>> A change was introduced In JDK-8264770 that swaps the use of
>> ChangeListeners to InvalidationListeners within the internal
>> implementation of BidirectionalBinding [1].
>>
>> While this change shouldn't normally affect third party applications, it
>> turned out to break the scrolling facilities used by the widely used
>> rich text widget RichTextFX [2].
>>
>> After a short investigation, I believe the root cause lies within
>> another library by the same author called ReactFX [3], which aims to
>> bring reactive programming techniques to JavaFX; in order to do so it
>> seems to expands on but also sometime overrides the built-in bindings
>> and events mechanisms.
>>
>> Now, I do believe that this is probably an exceptional case, and it is
>> also quite possible that it  is the result of an unsafe/incorrect use of
>> internal implementations by the third party library, but with that said
>> I can't help but feeling a bit nervous about the wider implications of
>> that change with regard to compatibility of existing apps and OpenJFX
>> 17. At the very least I believe it is important to raise awareness about
>> potential compatibility issues among the community.
>>
>> For your information, I reached out to the maintainers of RichTextFX and
>> proposed a workaround (replacing the use of a bidirectional binding by a
>> pair of explicit ChangeListeners), which, while not very elegant, seems
>> to fix the particular issue I discovered [4], but unfortunately it seems
>> development on the underlying ReactFX is no longer active (last commit
>> in 2016).
>>
>> -- Fred
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8264770
>>
>> [2] https://github.com/FXMisc/RichTextFX
>>
>> [3] https://github.com/ReactFX/reactfx.github.io
>>
>> [4] https://github.com/FXMisc/Flowless/issues/97
>>
>