RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v3]

[Nir Lisker]

On Mon, 17 Feb 2025 23:47:57 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> With that I mean that when you add a listener to a property during its own notification, that listener will not be called until a change occurs after the notification completes (ie. the change must be triggered by some 3rd party, not during the fire value changed callback).

OK, now I understand.

> > So in the first case, the value is corrected.
> 
> I'm unsure what you mean by corrected here

I mean compared to the old behavior. In the old behavior, the listener was notified with an incorrect old value, while with the prospective new code (with added listeners) the listener will be notified with a correct value. With the current new code the listener isn't notified at all. So, the behavioral change, instead of incorrect->nothing, will be incorrect->correct.

In the second case I listed, instead of the current nothing->nothing (no behavioral change), it will be nothing->correct.

> But is it a specified behavior or just an implementation artifact of `ExpressionHelper`?

No, thankfully, very little is specified. This allows us to implement a more sensible behavior...

> For me, the main question would be: "Does it make sense for a listener added during a notification to immediately partake in the notification that added it?".
> ...
> * Notify new listeners near the end (because they're appended, not for any other reason) as part of a higher level (top level?) change in all cases, nested or not
>   *  This means a newly added listener even in the simple case gets the notification of the one that added it (this may be quite surprising, and we'll have to see if FX even builds if I do this :))
> * Never notify new listeners when an ongoing change is going on (ie. while the property is "busy" in a callback)
>   *  This is the current implementation, and will probably do exactly what ExpressionHelper does in 99.9% of the cases

I'm not sure myself if it makes sense since I've never done this and cared about the behavior. I suppose it could go either way. If the first way is too complicated, the second one (this PR) is also reasonable.

> One immediate problem however is that the `newValue` received may differ from a direct `get`

I think it should be specified that these are the same, no?

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

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2664284987