RFR: jsr166 jdk integration 2018-05

[David Holmes]

On 17/05/2018 4:25 AM, Stuart Marks 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.

No it's not "the fallacy of composition". Just because some operations 
can not compose it does not follow that no operations can ever compose.

>> 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 

Yes but believe me it was discussed a LOT when we introduced the 
concurrency utilities! :)

> 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. 

That seems an attempt at legitimising straying from the original intent, 
rather than recognizing that straying away from that intent should have 
been considered a bug.

Besides, ArrayList clearly documents that original intent: "if the list 
is structurally modified ...".

> The wording around CME and fail-fast is very pragmatic, so it 
> sense to be pragmatic about this issue.

I think I am being pragmatic. A change in content is not a change in 
structure. CME is inappropriate in such circumstances IMHO.

It seems to me that inconsistencies have been allowed to creep in wrt. 
concurrent "modifications" and throwing CME. Now that is recognized we 
have the dilemma of undoing past mistakes or embracing a stronger 
(undocumented) notion of "concurrent modification" and applying it 
uniformly. Neither path is smooth unfortunately.

David
-----

> s'marks