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
