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

[John Hendrikx]

On Mon, 20 Feb 2023 05:42:43 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This contains the following:
>> - Nested changes or invalidations using ExpressionHelper are delayed until the current emission completes
>>   - This fixes odd change events being produced (with incorrect oldValue)
>>   - Also fixes a bug in ExpressionHelper where a nested change would unlock the listener list early, which could cause a `ConcurrentModificationException` if a nested change was combined with a remove/add listener call
>> - A test for ExpressionHelper to verify the new behavior
>> - A test for all *Property and *Binding classes that verifies correct listener behavior at the API level (this tests gets 85% coverage on ExpressionHelper on its own, the only thing it is not testing is the locking behavior, which is not relevant at the API level).
>> - A fix for `WebColorFieldSkin` which triggered a nested change which used a flag to prevent an event loop (I've changed it now to match how `DoubleFieldSkin` and `IntegerFieldSkin` do it
>
> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Ensure change listeners are not called recursively (single and generic)
>  - Remove left over System.out.println's
>  - Introduce Emission enum to make logic clearer
>    
>    The logic only has three states, but using two booleans for this allows
>    for four states.

(about removing listener during event emission)

> Because listener A is removed in B, we hit the inconsistency with 1 listener again. I need to work through this, but I'm not convinced this is what the output should be. One glaring question is, are nested listener additions/removals also deferred, or do they take effect immediately, in which case they shouldn't receive deferred nested events I think.

I've fixed the 1 listener case so it doesn't do the call recursively.  I'll now take a look at listener addition/removal part.  I think that a follow up emission triggered by a nested change should use the latest set of listeners and not continue using the initial set (that's how the old code behaved).

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

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