RFR: JDK-8067969 Optimize Stream.count for SIZED Streams

[Paul Sandoz]

On Mar 12, 2015, at 1:07 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
>>>> I am pondering adding an api note to the count methods to head off any suprises as now the stream pipeline may not be executed.
>>> 
>>> I think it would be good to add a note to the spec, as this could be surprising.
>>> 
>>> So really this comes down to the type if intermediate operations, right?
>> 
>> And what optimizations the implementation can do.
>> 
>> 
>>> For example, filter will always be executed:
>>> 
>>> IntStream.of(1, 2, 3, 4).peek(System.out::println).filter(x -> true).count();
>>> 
>> 
>> Yes.
>> 
>> 
>>> Should the note capture something about the type of the intermediate operations?
>>> 
>> 
>> How about:
>> 
>> * @apiNote
>> * An implementation may choose to not execute the stream pipeline (either
>> * sequentially or in parallel) if it is capable of computing the count
>> * directly from the stream source.  In such cases no source elements will
>> * be traversed and no intermediate operations will be evaluated.
>> * Behavioral parameters with side-effects, which are strongly discouraged
>> * except for harmless cases such as debugging, may be affected.  For
>> * example, consider the following stream:
>> * <pre>{@code
>> *     List<String> l = ...
>> *     long count = l.stream().peek(System.out::println).count();
>> * }</pre>
>> * The number of elements covered by the stream source, a {@code List}, is
>> * known and the intermediate operation, {@code peek}, does not inject into
>> * or remove elements from the stream (as may be the case for
>> * {@code flatMap} or {@code filter} operations).  Thus the count is the
>> * size of the {@code List} and there is no need to execute the pipeline
>> * and, as a side-effect, print out the list elements.
> 
> Looks good to me.
> 

Webrev updated:

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8067969-optimize-stream-count/webrev/

Paul.