RFR: JDK-8304439: Subscription based listeners [v7]

[John Hendrikx]

On Sun, 9 Jul 2023 19:34:23 GMT, Michael Strauß <mstrauss at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 345:
>> 
>>> 343:         ChangeListener<T> listener = (obs, old, current) -> subscriber.accept(current);
>>> 344: 
>>> 345:         subscriber.accept(getValue());  // eagerly send current value
>> 
>> What is the reason of this logic being done only for the Consumer and not for the BiConsumer (or the Runnable for that matter)?
>
> There doesn't seem to be a way to do the same for the other overloads:
> * The `Runnable` overload is specified to be invoked _when the value becomes invalid_, which isn't happening when a subscription is added. Eagerly invoking the runnable without a valid->invalid transition does not conform to the specification of an invalidation listener.
> * The `BiConsumer` overload accepts two values: the old value and the new value. But we don't know the old value, we only know the current value. Using the current value as both old and new value does not conform to the specification of a change listener.

The reasoning is that this would be the most logical and convenient way for these subscriptions to work.  I think mstr2 said it well, but I'll run them down as well:

Invalidation subscribers are called when the property actually becomes invalid; since it may currently be valid, calling the subscriber immediately would send the wrong signal.  A case could be made to call the subscriber immediately if it is currently invalid, but I think whatever we choose here, it should work the same way as the current `addListener(InvalidationListener)` -- I'm pretty sure this one doesn't call the listener immediately when the property is currently invalid (this is something of a gotcha as well for beginning users of `InvalidationListener`s).

Change subscribers require the old value; this is only temporarily available when there's an actual change in the property. Old values are not cached, and can't be cached as this may prevent garbage collection of whatever the old value references.

The value listeners are a new breed, and specifically set up for convenient use.  They're also the only ones that can send a sensible initial value, and since I'm pretty sure that's almost always what you'd want, this is the default for this type of subscription.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1069#discussion_r1257536996