On Mon, 20 Feb 2023 05:42:43 GMT, John Hendrikx <jhendr...@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
