On Thu, 16 Jan 2025 00:31:16 GMT, Michael Strauß <mstra...@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
