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

[Andy Goryachev]

On Thu, 16 Jan 2025 00:31:16 GMT, Michael Strauß <mstrauss at openjdk.org> wrote:

>> 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?
>
> The way I see it, the situation that erroneously triggers `ConcurrentModificationException` only happens when `VetoableListDecorator` accesses its own sublist:
> 
>     try {
>         modCount++;
>         boolean ret = list.addAll(index, c); // --> c is its own sublist
>         ...
> 
> 
> Since `modCount` is modified first, and the sublist refers back to the same modified `modCount`, the exception occurs. It can't occur when we are dealing with another list (or a sublist of another list), since in this case there is no self-referential conflict.
> 
> The way `ArrayList` circumvents this problem is by incrementing `modCount` only after the operation is done, not before it has started; it doesn't create a defensive copy.

Thank you for clarification!  I'll try to come up with a test (and I think even if I succeed, it does not mean that your solution is not good, since the caller can always create a defensive copy themselves).

BTW, what were you doing to trigger this bug?

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

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