RFR: jsr166 jdk integration 2018-05

[Martin Buchholz]

On Wed, May 16, 2018 at 11:25 AM, Stuart Marks <stuart.marks at oracle.com>
wrote:

>
>
> On 5/15/18 7:37 PM, David Holmes wrote:
>
>> I'm still with Martin on this. It makes no sense to me to allow replacing
>> one element to not cause CME, but replacing more than one does cause CME.
>> This is inconsistent and confusing and the end result is the programmer
>> won't know what to expect when or why.
>>
>
> This is the fallacy of composition, that if a single operation has some
> property, then an arbitrary composition of those operations must also have
> that property. This is decidedly not true for many things. Consider
> atomicity for example. My claim is that the setting of an individual
> element is qualitatively different from a bulk operation.
>

(We don't seem to be moving towards consensus ...)

atomicity is "obviously" a non-composable property of an operation, but
contrarily "does not modify" is "obviously" composable.

Having replaceAll increment modCount is almost as wrong as having forEach
increment modCount, even though """forEach is qualitatively different from
get()."""

Incrementing modCount is introducing a subtle race into plausible user code
that would otherwise be correct.

At the very least, having replaceAll increment modCount (inconsistently!)
is surprising to users and is not documented anywhere.