https://linen.dev logo
#ask-ai
Title
# ask-ai
c

charles

12/14/2020, 11:31 PM
I learned something today. Anyone able to guess what this code snippet prints out? It's a stream flatmapped inside a stream flatmapped inside a stream. I'll put the answer in the thread, so don't open the thread if you want to puzzle about it first.
Copy code
public static void main(String[] args) {
    final Stream<Integer> stream = Stream.of(1)
        .peek(i -> System.out.println("outer stream"))
        .flatMap(i -> {
          return Stream.of(1)
              .peek(i1 -> System.out.println("middle stream"))
              .flatMap(i2 -> {
                return Stream.of(1).peek(i3 -> System.out.println("inner stream"))
                    .onClose(() -> System.out.println("inner stream closed"));
              })
              .onClose(() -> System.out.println("middle stream closed"));
        }).onClose(() -> System.out.println("outer stream closed"));

    System.out.println("collection is about to start");
    stream.collect(Collectors.toList());
    System.out.println("collection is done");
  }
answer:
Copy code
collection is about to start
outer stream
middle stream
inner stream
inner stream closed
middle stream closed
collection is done
the outer stream, while operated upon is never closed.
j

Jared Rhizor (Airbyte)

12/14/2020, 11:34 PM
huh
so this is because it’s autoclosable but the stream isn’t in a closure that tries-with-resources?
c

charles

12/14/2020, 11:36 PM
it does mean if you need to guarantee a stream gets closed if it is fully consumed but don't trust the consumer to close it you can do something like this i think.
Copy code
thisStreamMayNotBeClosed = Stream.of(1).flatMap(i -> butThisStreamWillBeClosed);
j

Jared Rhizor (Airbyte)

12/14/2020, 11:40 PM
so wrapping the whole stream assignment in a
try
works, which makes sense to me
c

charles

12/14/2020, 11:40 PM
yup.
j

Jared Rhizor (Airbyte)

12/14/2020, 11:40 PM
it isn’t clear to me why the
close
is getting called in the flatmap case
it just kind of says
flatMap
does close streams for you
I must be missing something when looking for it while exploring code in
java.util.stream
oh no I’m just blind
under the hood the flatmap is taking the stream and doing a try with resources in
java.util.stream.ReferencePipeline.flatMap
🎉 1
cool
were we not closing something somewhere?
c

charles

12/14/2020, 11:48 PM
nah. nothing wrong yet anyway.
i was playing with how to handle onclose on some db queries in the jdbc source.
j

Jared Rhizor (Airbyte)

12/14/2020, 11:48 PM
ah
c

charles

12/14/2020, 11:49 PM
and now i know i can force it, which is neat.
r

Roshan George

12/15/2020, 12:24 AM
c

charles

12/15/2020, 12:24 AM
yes! definitely.
r

Roshan George

12/15/2020, 12:25 AM
Interestingly, does it close streams that are 'from outside'? Let me try.
c

charles

12/15/2020, 12:25 AM
i have a case where the stream is created in a method but is consumed by some outside consumer. so i can't try-with-resource it, but i want a guarantee that when it has been consumed, on close is called.
contrived example:
r

Roshan George

12/15/2020, 12:28 AM
Oh interesting, so when someone finishes consuming
thisStreamMayNotBeClosed
you will close
butThisStreamWillBeClosed
. That's a pretty clever use.
🎉 1
c

charles

12/15/2020, 12:28 AM
Copy code
public static class StreamMaker {
    public static Stream<Integer> makeStream() {
      return Stream.of(1).onClose(() -> System.out.println("close a vital resource");
    }
  }

  public static void main(String[] args) {
    // external caller fails to call close!
StreamMaker.makeStream().collect(Collectors.toList());
  }
but wrapping in the flatmap gives me the guarantee.
Copy code
public static class StreamMaker {
  public static Stream<Integer> makeStream() {
    return Stream.of(1).flatMap(i -> Stream.of(1).onClose(() -> System.out.println("close a vital resource"));
  }
}

public static void main(String[] args) {
  // external caller fails to call close, but it is okay because we are wrapped in a flatMap.
StreamMaker.makeStream().collect(Collectors.toList());
}
r

Roshan George

12/15/2020, 12:40 AM
I was thinking to myself why all stream terminal operations do not cause a Stream#close since no stream is usable post-terminal-operation. After all: • All Streams are unusable post-terminal-operation • Non-IO-streams don't need the close so Stream#close is unnecessary there • IO-streams need the close in some cases and not others but that is a property of the underlying thing (e.g. a Files#lines obviously needs a File#close right after terminal, but a Connection#close shouldn't be called after you read all the rows) So the choice must be because it simplifies the common case in the API use.
👍 1
There's probably a mailing list somewhere where people are discussing this.
My personal confession is that I did not even know
Stream#close
existed.
c

charles

12/15/2020, 12:42 AM
legit. i think it's pretty common that people forget about
Stream#close
. i didn't really realize it existed until the last couple years.
j

Jared Rhizor (Airbyte)

12/15/2020, 12:49 AM
post-terminal-operation
in the original example there is no clearly terminal operation, which is one difficulty
After today I’m pretty sure I’ve written some code that doesn’t close streams properly…
r

Roshan George

12/15/2020, 12:51 AM
Stream#collect
is terminal, right?
c

charles

12/15/2020, 12:52 AM
yeah. you can't operate on the stream. anymore after that.
but it is not technically closed.
r

Roshan George

12/15/2020, 12:52 AM
j

Jared Rhizor (Airbyte)

12/15/2020, 12:53 AM
ooh
yeah
it is labelled as terminal
I guess something that implements
Stream
could be using an underlying resource for some other methods even if the stream has been terminated? Therefore it doesn’t make sense to autoclose?
2 Views