RFR: jsr166 jdk integration 2018-05

[Martin Buchholz]

On Mon, May 14, 2018 at 12:18 PM, Paul Sandoz <Paul.Sandoz at oracle.com>
wrote:

>
>> A CME is not necessarily associated with just structural modifications it
>> could, on a best effort basis, be associated with any modification, which
>> is cheaper to do for bulk operations rather than individual operations, and
>> this operation can be used to perturb all the elements of the list (just
>> like sort) causing strange and hard to track bugs while in the middle of
>> iterating. IMHO its better to fail under such circumstances rather than be
>> silent.
>>
>
> It's tempting to treat modCount as a count of ALL modifications,
> especially given its name, but that's different from the historical
> behavior and design of these classes.  Consistency with existing spec and
> implementations is the biggest argument.
>
>
> 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.  A user can
semi-reasonably decide to call ArrayList.replaceAll while an iteration is
in progress (in the same thread).

Or for Vector, imagine occasional gc-like vector.replaceAll(x ->
optimizedDropInReplacementFor(x))

If we implicitly revised the definition of modCount, that seems like a bug
to me.