OpenJDK8: java.util.stream.Stream.onClose

[Paul Sandoz]

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 <varming at 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