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

[Paul Sandoz]

On Nov 19, 2012, at 11:26 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> 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.
> 

I tend to agreed.

Perhaps we can state something along the lines that unless otherwise stated forEach implementations are not fail-fast.

Paul.