RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap

[Paul Sandoz]

On Jun 13, 2013, at 10:15 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> On 06/13/2013 09:51 AM, Paul Sandoz wrote:
>> On Jun 13, 2013, at 7:28 AM, Mike Duigou <mike.duigou at oracle.com> wrote:
>> 
>>> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>>> 
>>> Revised webrev:
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>>> 
>> The approach we have taken for bulk traversal of fail-fast spliterators and ArrayList/Vector is to check the mod count at the end of the loop. I think we should be consistent with those.
>> 
>> Paul.
> 
> Hi Paul,
> ArrayList.forEach() does the modCount check at each step.

Doh, yes, i mis read the logic in the for statement in ArrayList/Vector.


> There is a difference between an Iterator/forEach and a spliterator/stream,
> with a stream you know that the called lambdas will not interfere and mutate the source collection.
> 

You do? I don't think there is any conceptual difference between the following w.r.t. interference:

  ArrayList l = ...
  l.stream().filter(...).forEach(e -> l.add(e));
  l.spliterator().forEachRemaining(e -> l.add(e));

and:

  ArrayList l = ...
  l.forEach(e -> l.add(e));
  l.iterator().forEachRemaining(e -> l.add(e));

Of course we have (or will have) strong wording saying don't implement interfering lambdas, but we still have to check for co-modification in the traversal methods of ArrayList spliterator.

So we are still inconsistent between Spliterator.forEachRemaining and Iterator.forEachReamining/Collection.forEach.

Paul.