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

Paul Sandoz paul.sandoz at oracle.com
Thu Mar 12 09:44:09 UTC 2015


On Mar 11, 2015, at 1:45 PM, Aggelos Biboudis <biboudis at gmail.com> wrote:

> Hi all,
> 
> Please review the patch for the count terminal operator on SIZED streams.
> 
> https://bugs.openjdk.java.net/browse/JDK-8067969
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8067969-optimize-stream-count/webrev/
> 
> Thanks Paul Sandoz for sponsoring this.
> 

This looks good. Code is nicely contained and not as much as i initially anticipated.

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.

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

WDYT?

Paul.



More information about the core-libs-dev mailing list