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

[John Hendrikx]

On Tue, 18 Feb 2025 00:53:59 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Regarding vetoing, I noticed that only the first registered listener can veto since it overrides any subsequent value set.
> 
> Suppose listener A changes the value to 5, B changes it to 6, C changes it to 7, and Z does nothing, then upon setting a value from 0 to 1 we will see:
> 
> ```
> A sees 0->1; sets to 5
>   A sees 1->5
> B sees 0->5; sets to 6
>   A sees 5->6; sets to 5
>     A sees 6->5
> C got 0->5; sets to 7
>   A sees 5->7; sets to 5
>     A sees 7->5
> Z sees 0->5
> ```
> 
> Is this intended?

That's an interesting case. B is not notified that the value reverted to 5, as it was already previously notified with 5 (the call would be `5 -> 5` which is skipped).  If we did however, we'd have an infinite loop which such unconditional vetoing going on.

There can however be conditional vetoing. A case where A allows only positive values and B allows only uneven values would run like this:

Value is set from 0 to -4.

    A sees 0 -> -4; changes it to 4
       A sees -4 -> 4; does nothing
    B sees 0 -> 4; changes it to uneven 5
       A sees 4 -> 5; does nothing
       B sees 4 -> 5; does nothing
    C sees 0 -> 5

I'm not sure what to think of this, and whether it needs a fix, and if so, what that fix should be...

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

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