RFR: 8347753: VetoableListDecorator doesn't accept its own sublists for bulk operations [v2]

[Andy Goryachev]

On Mon, 27 Jan 2025 18:34:30 GMT, Michael Strauß <mstrauss at openjdk.org> wrote:

>> Passing a `VetoableListDecorator.subList()` to any of its bulk operations (`addAll`, `setAll`, `removeAll`, `retainAll`) throws `ConcurrentModificationException`. The reason is that the `VetoableListDecorator.modCount` field is incremented before the underlying list's bulk operation is invoked, which causes a mismatch when the sublist is interrogated by the bulk operation.
>> 
>> However, simply updating the `modCount` field _after_ the underlying list was modified also doesn't work, as in this case listeners can't see the correct value for `modCount` in their callback. The fix is to make a defensive copy of the sublist before invoking the underlying list's bulk operation.
>
> Michael Strauß has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - update tests
>  - update tests
>  - check list content in tests
>  - Merge branch 'master' into fixes/vetoable-list-decorator-sublist
>  - allow sublists to be used for bulk operations
>  - failing tests

> Can you elaborate?
> what does "save one extra pointer" mean?

What I mean is simply get rid of the extra pointer like `VetoableListIteratorDecorator.parent` and the related logic, and simply create a copy of List/Collection each time.

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

PR Comment: https://git.openjdk.org/jfx/pull/1679#issuecomment-2616624138