On Jun 13, 2013, at 10:15 AM, Remi Forax <fo...@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.dui...@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.
