> On May 14, 2018, at 5:51 PM, David Holmes <david.hol...@oracle.com> wrote: > > On 15/05/2018 7:56 AM, Paul Sandoz wrote: >>> On May 14, 2018, at 2:04 PM, Martin Buchholz <marti...@google.com> wrote: >>> On Mon, May 14, 2018 at 1:45 PM, Paul Sandoz <paul.san...@oracle.com >>> <mailto:paul.san...@oracle.com>> wrote: >>>> On May 14, 2018, at 12:43 PM, Martin Buchholz <marti...@google.com >>>> <mailto:marti...@google.com>> wrote: >>>> On Mon, May 14, 2018 at 12:18 PM, Paul Sandoz <paul.san...@oracle.com >>>> <mailto:paul.san...@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. >>> >>> Why not? It can "perturb it in such a fashion that iterations in progress >>> may yield incorrect results”. >>> >>> Why? It replaces every element "inplace" in the style of List.set(i) which >>> is also not a structural modification. >> I get that, but I would argue that (placing the implementation aside) the >> bulk operation as a whole is compatible with the “otherwise” part of the >> modCount definition, since it can perturb the list and effect the yet to be >> traversed elements. Such usage is a likely source of hard to track down bugs >> that CMEs are designed to help flag. >> I doubt i am gonna change your mind on this :-) So we may just have to agree >> to disagree on the interpretation of the definition and move on. I would >> prefer it remains but it's your call. > > FWIW I agree with Martin - sorry Paul :)
That’s ok. Its clear i am out numbered here, and overspent my budget on debating CME for the month :-) Paul.
