Java 8 Stream (based on resource) .iterator() that auto-closes the resource?

Question

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?

Answer 1

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();