7

Does Java 8 Stream.iterator() auto-close the stream when it's done? I suppose not...

I have something like this:

class Provider implements Serializable {

  Iterator<String> iterator() {
    Stream<String> stream = new BufferedReader(...).lines();
    return stream.iterator();
  }
}

This iterator is used by some other class that doesn't know the iterator is based on a file-reading resource. That is

class Consumer {
  void f() {
    Iterator<String> iterator = provider.iterator();
    // code that calls iterator methods at non-determined times
  }
}

I have to stream the file because it's too large to fit into memory. But I'd like to be able to auto-close the resource when the iterator doesn't have any more elements, so that I don't have leaked resources. The Provider class is Serializable and I can't have either the Stream or the BufferedReader as members.

Is there a good way to do this?

webuster
  • 2,490
  • 18
  • 27
  • 4
    You could make an `AutoClosingIterator` wrapper. But i wouldn't recommend it because it's fragile: if the consumer of the iterator fails before exhausting it, you get a resource leak. – Marko Topolnik Dec 02 '16 at 14:59
  • Thanks for the suggestion - anything else that gives me a little more control? – webuster Dec 02 '16 at 15:22
  • 2
    Nothing can save you from the consumer abandoning the iterator. Only changing the contract for the consumer can help. – Marko Topolnik Dec 02 '16 at 15:24
  • 1
    Just use `return Files.readAllLines(…).iterator();`. Then, the resource is already closed when the method returns. – Holger Dec 02 '16 at 15:27
  • 1
    Ah geez. I forgot to mention. I *have* to stream because the file is too large to fit in memory. – webuster Dec 02 '16 at 15:29
  • 2
    This is definitely one of the worst case scenarios. Letting code work with a resource without knowing that it is working with a resource is unlikely to have a clean solution. Maybe the caller of `f()` can signal the completion to `Provider`… – Holger Dec 02 '16 at 15:33
  • The `Consumer` actually wants to consume it all, but `AutoClosingIterator` doesn't cut it, because failing half-way leaks my resources. – webuster Dec 02 '16 at 15:36
  • 2
    As I said, when the consumer doesn’t know that there is a resource to close, only the caller of `f()` knows when it completed. – Holger Dec 02 '16 at 15:37
  • see also https://stackoverflow.com/q/34072035/32453 – rogerdpack Jan 02 '18 at 19:45

1 Answers1

2

First, please note that your stream created from BufferedReader.lines does not hold any resource, thus closing the stream has no effect:

BufferedReader br = new BufferedReader(...);
try(Stream<String> stream = br.lines()) {
   ... use stream
}
// br is still open here!

Usually it's explicitly documented if the stream holds a resource. For example, Files.lines documents this:

The returned stream encapsulates a Reader. If timely disposal of file system resources is required, the try-with-resources construct should be used to ensure that the stream's close method is invoked after the stream operations are completed.

There's no such remark in BufferedReader.lines documentation.

So in your case it's your responsibility to close the BufferedReader if it actually holds a resource which needs to be closed. That's not always the case. For example, if you create new BufferedReader(new StringReader(string)), you don't have any resource to close, so it's just as fine not to call the close() method at all.

Anyways, back to your question. Assuming that the stream actually holds a resource (e.g. created from Files.lines()), it will not be closed automatically if you just return an iterator, regardless whether the iterator is traversed to the end or not. You have to explicitly call the close() method on the stream if you want to close it at some particular moment. Otherwise you have to rely on garbage collector which will eventually put the underlying resource Object (e.g. FileInputStream) into the finalization queue which will eventually call the finalize method of that object which will close the file. You cannot guarantee when this happens.

An alternative would be to buffer the whole input file into memory (assuming that it's not very long) and close the file before returning an iterator. You can do this for reading the file without any stream API:

return Files.readAllLines(pathToTheFile).iterator();
Tagir Valeev
  • 97,161
  • 19
  • 222
  • 334