Timo Kinnunen timo.kinnunen at
Sat Jan 23 09:50:09 UTC 2016


The pipeline stages don’t really need to mutate themselves (as they can mutate the Stream if needed). So they should be shareable between Streams, alleviating some of cost of creating new copies of a Stream, right? 

Have a nice day, 

Sent from Mail for Windows 10

From: Paul Sandoz
Sent: Friday, January 22, 2016 18:45
Cc: core-libs-dev Libs
Subject: Re: OpenJDK8:

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.


> On 22 Jan 2016, at 17:14, Carsten Varming <varming at> 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;
> 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]
> Carsten

More information about the core-libs-dev mailing list