On Sun, 7 Sep 2025 00:12:31 GMT, Michael Strauß <[email protected]> wrote:
> While a `ListChangeListener` can receive notifications for bulk operations
> (`addAll`, `removeAll`, `clear`, etc.), `SetChangeListener` and
> `MapChangeListener` only receive notifications for individual
> add/replace/delete operations. For example, when mappings are added to an
> `ObservableMap` with `putAll()`, listeners will be invoked once for each
> individual mapping.
>
> Since there is no way for a `SetChangeListener`/`MapChangeListener` to know
> that more changes are coming, reacting to changes becomes difficult and
> potentially inefficient if an expensive operation (like reconfiguring the UI)
> is done for each individual change instead of once for a bulk change
> operation.
>
> I think we can improve the situation by adding a new method to
> `SetChangeListener.Change` and `MapChangeListener.Change`:
>
>
> /**
> * Gets the next change in a series of changes.
> * <p>
> * Repeatedly calling this method allows a listener to fetch all subsequent
> changes of a bulk
> * map modification that would otherwise be reported as repeated invocations
> of the listener.
> * If the listener only fetches some of the pending changes, the rest of the
> changes will be
> * reported with subsequent listener invocations.
> * <p>
> * After this method has been called, the current {@code Change} instance is
> no longer valid and
> * calling any method on it may result in undefined behavior. Callers must
> not make any assumptions
> * about the identity of the {@code Change} instance returned by this method;
> even if the returned
> * instance is the same as the current instance, it must be treated as a
> distinct change.
> *
> * @return the next change, or {@code null} if there are no more changes
> */
> public Change<E> next() { return null; }
>
>
> This new method allows listener implementations to fetch all subsequent
> changes of a bulk operation, which can be implemented as follows:
>
>
> set.addListener((SetChangeListener) change -> {
> do {
> // Inspect the change
> if (change.wasAdded()) {
> ...
> } else if (change.wasRemoved() {
> ...
> }
> } while ((change = change.next()) != null);
> }
>
>
> The implementation is fully backwards-compatible for listeners that are
> unaware of the new API. If the `next()` method is not called, then all
> subsequent changes are delivered as usual by repeated listener invocations.
>
> If a listener only fetches some changes of a bulk operation (but stops
> halfway through the operation), the remaining changes will also be delivered
> with repeated listener invocati...
Before going into a full review, I'd like t ask this:
1. please enumerate all the bulk methods in `Map` and `Set` that support the
new behavior in the description and possibly in the javadoc
2. do we have tests that cover all the bulk methods, exercising the following
three scenarios:
- `next()` is not called, received all changes individually (probably so, as it
is the current behavior)
- partial retrieval scenario where the remaining changes are received via
individual events as described in javadoc and the description
- all changes received via the new methods
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1885#issuecomment-3437897119
