hg: lambda/lambda/jdk: Streams cleanups; add optimized forEach implementations; include subList in tested lists

[Remi Forax]

On 11/19/2012 01:53 PM, Paul Sandoz wrote:
> On Nov 19, 2012, at 11:51 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> On 11/19/2012 10:47 AM, Paul Sandoz wrote:
>>> On Nov 18, 2012, at 9:28 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:
>>>
>>>>> A code like this should throw a CME and not an AIOOBE
>>>>> arraylist.forEach(e -> { arraylist.remove(e); })
>>>> The current code won't do that, as it copies the array into a local var
>>>> before the loop, so the indexes are always valid.
>>>>
>>>> A reasonable middle ground is a comodification check after the loop
>>>> terminates.
>>>>
>>> Yes, that's what Mike did with the original array proxy stuff.
>>>
>>> It's not a fail-fast solution thus risks "arbitrary, non-deterministic behavior at an undetermined time in the future", but i think it is within the scope of ConcurrentModificationException.
>> The question is why ArrayList.forEach should not be fail-fast ?
> I think we have to consider the wider context of Iterable/Iterator/Spliterator.forEach when used for parallel evaluation. In such cases it is advantageous not to fail-fast.

I agree, for parrallel evaluation, forEach is not necessary fail-fast 
but it has to be or snapshot or weekly consistent
and not to have an undefined behaviour.

>
> So while there is a precedent for the Iterator impls to fail-fast it does not necessarily mean all forEach impls should by default do the same.

forEach doesn't have to be fail-fast but ArrayList.forEach has to be 
failfast.

>
> Paul.
>

Rémi