Hi Carsten,
If you read the documentation further on down it states:
* first exception, since an exception cannot suppress itself.) May
* return itself.
The same applies to parallel/sequential/unordered. For these cases it would be
rather inefficient to create new stages in the pipeline, for essentially
functional no-ops regarding actual element processing, and would likely
increase the cost when performing the terminal operation.
Paul.
> On 22 Jan 2016, at 17:14, Carsten Varming <varm...@gmail.com> wrote:
>
> Dear core-libs-devs,
>
> I was playing around with streams and onClose and ran into an example with
> odd behavior (well, I found it odd, see example below). I was wondering if
> you could point me to prior discussions on semantics of intermediate
> operations and the semantics of Stream.onClose.
>
> A bit of code so we have something concrete to discuss:
>
> import java.util.stream.Stream;
>
> public class Example {
> public static void main(String[] args) {
> final Stream<String> foo = Stream.of("1", "2", "3");
> final Stream<String> bar = foo.onClose(() ->
> System.out.println("Closing bar"));
>
> try (final Stream<String> s = foo) {
> s.forEach(System.out::println);
> }
> }
> }
>
> When I run the program above I get:
> 1
> 2
> 3
> Closing bar
>
> Hmm, the onClose call mutated foo. This is surprising to me as when I read
> [1] it says onClose is an intermediate operation and I quote: "Returns an
> equivalent stream with an additional close handler.". The documentation
> does not mention that the stream passed to onClose is mutated. Is this the
> intended behavior or is it a bug? I hope it is a bug, but I would like to
> understand the reasons for the current implementation.
>
> [1]
> https://docs.oracle.com/javase/8/docs/api/java/util/stream/BaseStream.html#onClose-java.lang.Runnable-
>
> Carsten
