RFR: jsr166 jdk integration 2018-05

[Stuart Marks]

>>>>> I mentally revised the history when doing the collections/stream API work since we added more bulk operations, since this is on a “best effort” basis and if it’s cheap to do then there is no real harm in it and it might help.
>>>>>
>>>>> Spec says:
>>>>>
>>>>> """protected transient int modCount
>>>>>
>>>>> The number of times this list has been structurally modified. Structural modifications are those that change the size of the list, or otherwise perturb it in such a fashion that iterations in progress may yield incorrect results."""
>>>>>
>>>>> replaceAll doesn't qualify as a structural modification.
>>>>
>>>> Why not? It can "perturb it in such a fashion that iterations in progress may yield incorrect results”.
>>>>
>>>> Why?  It replaces every element "inplace" in the style of List.set(i) which is also not a structural modification.
>>> I get that, but I would argue that (placing the implementation aside) the bulk operation as a whole is compatible with the “otherwise” part of the modCount definition, since it can perturb the list and effect the yet to be traversed elements. Such usage is a likely source of hard to track down bugs that CMEs are designed to help flag.
>>> I doubt i am gonna change your mind on this :-) So we may just have to agree to disagree on the interpretation of the definition and move on. I would prefer it remains but it's your call.
>>
>> FWIW I agree with Martin - sorry Paul :)
> 
> That’s ok. Its clear i am out numbered here, and overspent my budget on debating CME for the month :-)

Don't give up so quickly, Paul. :-)

I remember working on the bulk operations back in JDK 8 (with Mike Duigou?) and 
we discussed the issue of bulk operations vs. concurrent modification.

Even though operations like replaceAll() and sort() don't "structurally modify" 
the list, our interpretation was that they did perturb in-progress iterations. 
These operations potentially change every element, thus an in-progress iteration 
is likely to observe some unspecified mixture of the "before" and "after" states 
of the list. That sounds like a programming error. The intent of CME is to 
prevent programming errors, so we focused on that instead of on "structural 
modification." The "perturb" clause seemed to cover this behavior, so we left 
that part of the spec unchanged.

Note that in JDK 8, both ArrayList's and Vector's replaceAll() both will cause 
CME to be thrown by an in-progress iteration. I think the onus should be on 
Martin to show why replaceAll() should no longer trigger CME.

An alternative would be to adjust the specification of modCount to clarify that 
it accommodates bulk modifications that aren't strictly structural modifications.

s'marks