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

Paul Sandoz paul.sandoz at oracle.com
Thu Jun 13 08:44:54 UTC 2013

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.

More information about the core-libs-dev mailing list