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

[Nir Lisker]

On Wed, 19 Feb 2025 01:09:59 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> I'm going to assume that A and B are aware of each other, and are somehow working together, as this scenario makes little sense otherwise. The code that is using these two listeners is then likely coming from the same implementation (how else would A have a reference to B).

Yes, here is an example:

        var property = new SimpleIntegerProperty(0);

        ChangeListener<? super Number> listenerB = (obs, ov, nv) -> {
        };

        ChangeListener<? super Number> listenerA = (obs, ov, nv) -> {
            property.set(5);
            property.removeListener(listenerB);
        };

        property.addListener(listenerA);
        property.addListener(listenerB);

        property.set(1);


> So, given that, if an implementation decides to remove B, no matter when that happens exactly (outside a notification call, or within one), would it be reasonable to expect a callback still?

Here is how I walked through this in my head:

A gets 0->1; sets 5
A gets 1->5; setting 5 does nothing
B gets 0->5
A removes B (in the 1->5 event)
A removes B (in the 0->1 event)

That is, after A reacts to the new value 5, it's B's turn to react *before* it's removed. It could be just me though.

> Here is a comparison table:

It looks good, but it doesn't strictly contradict the example. A listener should stop receiving notifications immediately when it's removed, but here it's not removed yet and still doesn't receive notifications.

 >I feel I also should point out that such dependencies between listeners (where listener A removes B, or adds C or whatever) can only happen in code that is aware of these other listeners. There is no way to obtain a reference to a listener from the system, and so all of these scenario's have perfect knowledge of what each listener does and their life cycles. There can be no surprises here, listeners can't be added or removed by some other class or 3rd party dependency without a reference to them.

Yes, this is just another case where I'm not sure we're doing the right thing, not that I'm sure we're not.

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

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