Do I need to close InputStream after I close the Reader

Question

I was wondering, whether is there any need for me to close the InputStream, after I close the reader?

try {     inputStream = new java.io.FileInputStream(file);     reader = new InputStreamReader(inputStream, Charset.forName("UTF-8")); } catch (Exception exp) {     log.error(null, exp); } finally {     if (false == close(reader)) {         return null;     }     // Do I need to close inputStream as well?     if (false == close(inputStream)) {         return null;     } } 

Answer 1

No, you don't have to.

Since the decorator approach used for streams in Java can build up new streams or reader by attaching them on others this will be automatically be handled by InputStreamReader implementation.

If you look at its source InputStreamReader.java you see that:

private final StreamDecoder sd;  public InputStreamReader(InputStream in) {   ...   sd = StreamDecoder.forInputStreamReader(in, this, (String)null);   ... }  public void close() throws IOException {   sd.close(); } 

So the close operation actually closes the InputStream underlying the stream reader.

EDIT: I wanna be sure that StreamDecoder close works also on input stream, stay tuned.

Checked it, in StreamDecoder.java

void implClose() throws IOException {   if (ch != null)     ch.close();   else     in.close(); } 

which is called when sd's close is called.

Answer 2

Technically, closing the Reader will close the InputStream. However, if there was a failure between opening the InputStream and creating the Reader, you should still close the InputStream. If you close the InputStream [the resource] there shouldn't be a good reason to close the Reader [the decorator]. There are also popular bugs where closing a decorator can throw an exception before closing the decorated. So:

Resource resource = acquire(); try {     Decorator decorated = decorate(resource);     use(decorated); } finally {     resource.release(); } 

There are some complications to watch out for. Some decorators may actually contain native resources due to their implementation. Output decorators will generally need to be flushed, but only in the happy case (so in the try not the finally block).