On Mar 12, 2015, at 1:07 PM, Chris Hegarty <chris.hega...@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.
