-
Bug
-
Resolution: Duplicate
-
P4
-
None
-
None
-
None
The change JDK-8067969 allowed Stream.count() to short-circuit if the size of the stream is known.
The specification for Stream.count() says:
* Returns the count of elements in this stream. This is a special case of
* a reduction and is equivalent to:
*
* return mapToLong(e -> 1L).sum();
[markup elided for clarity]
This makes it sound as if count() is defined in terms of mapToLong(e -> 1L).sum(). However, the @apiNote below describes the possibility of short-circuiting which seems to contradict the above.
It would probably be best if mapToLong(e -> 1L).sum() were removed from the specification portion of this method.
This would be a useful example to show in the case where the programmer explicitly wants to avoid the short-circuiting behavior, for example, if there is a peek() with side effects upstream in the pipeline.
The specification for Stream.count() says:
* Returns the count of elements in this stream. This is a special case of
* a reduction and is equivalent to:
*
* return mapToLong(e -> 1L).sum();
[markup elided for clarity]
This makes it sound as if count() is defined in terms of mapToLong(e -> 1L).sum(). However, the @apiNote below describes the possibility of short-circuiting which seems to contradict the above.
It would probably be best if mapToLong(e -> 1L).sum() were removed from the specification portion of this method.
This would be a useful example to show in the case where the programmer explicitly wants to avoid the short-circuiting behavior, for example, if there is a peek() with side effects upstream in the pipeline.
- duplicates
-
JDK-8130023 API java.util.stream: explicitly specify guaranteed execution of the pipeline
-
- Closed
-
- relates to
-
JDK-8130023 API java.util.stream: explicitly specify guaranteed execution of the pipeline
-
- Closed
-
-
JDK-8067969 Optimize Stream.count for SIZED Streams
-
- Closed
-