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

[Andy Goryachev]

On Wed, 15 Jan 2025 00:32:37 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.

modules/javafx.base/src/main/java/com/sun/javafx/collections/VetoableListDecorator.java line 391:

> 389: 
> 390:     /**
> 391:      * Returns the specified collection as an unmodifiable list that can safely be used in all bulk

Do you think it might be easier to create a defensive copy **always**?

In other words, can we guarantee that it is impossible for the user to create a convoluted code involving maybe two `VetoableListDecorators` where the second one loops back the changes to the first one, however ridiculous that might sound?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1679#discussion_r1917493626