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

[Nir Lisker]

On Sat, 18 Feb 2023 19:29:05 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Confusing me again here :-) Did you mean to say "breadth-first" where you said "depth-first" ?
> 
> Breadth first is for sure a lot easier, as the old values are much easier to get correct for it.
> 
> I've given depth first some more thought, but every approach I think of requires some kind of stack or tracking of which listeners weren't notified yet of the original set that we wanted to notify (and I think we'll need to remember even more if there is another change before the first and second one finishes).

Yes, sorry, I meant breadth-first. We can go with that one.

> @nlisker if we're going for breadth-first, shall I fix the cases for single listeners as well (finish the notification before calling the same listener again, instead of recursively calling into it?)

I think that we need to be consistent, so barring any special reason for excepting single listeners from this change, I would say that we need to bring them in line with the generic listener.

> Perhaps we could limit the explanation to just mentioning that its possible the "new value" may not be the same as ObservableValue#getValue if nested changes occured. Also, I'm curious why it would still be a bad practice to modify the value again (now that the old values are always correct); I think it's pretty much the standard pattern to veto a change (like a numeric field rejecting out of range values or non-numeric characters).

I'll think about what doc changes to make. We'll see what Ambarish thinks too.
Vetoing seems like a normal use case, but maybe there's another way of doing it. I never delved into this.

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

PR: https://git.openjdk.org/jfx/pull/837