RFR: jsr166 jdk integration 2018-05

[Stuart Marks]

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.

> The original intent of CME, from my recollections back in lead-up-to-Java-5 
> days, was to prevent iterators from breaking i.e. throwing exceptions, due to 
> the occurrence of the "concurrent" operation that changed the structure. It was 
> not intended as an indicator of a semantic programming error. Replacing one 
> element whilst there is a live iterator can be just as semantically wrong as 
> replacing them all.

CME, iterators, and the fail-fast concept were introduced in JDK 1.2 with the 
Collections Framework. The platform has evolved a LOT since then, so I don't 
think it's worthwhile to make a stand on original intent. The wording around CME 
and fail-fast is very pragmatic, so it sense to be pragmatic about this issue.

s'marks