RFR: 8367439: Bulk change notifications for ObservableSet and ObservableMap

[Andy Goryachev]

On Sun, 7 Sep 2025 00:12:31 GMT, Michael Strauß <mstrauss at openjdk.org> 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