Do I need to close InputStream after I close the Reader

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;
    }
}

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.

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).

You don't have to close stream, if you close() the reader.

> Closes the stream and releases any system resources associated with > it. Once the stream has been closed, further read(), ready(), mark(), > reset(), or skip() invocations will throw an IOException. Closing a > previously closed stream has no effect.

No you don't the reader will close the underlying InputStream

Acordding to source sniffing the reader closes its underlying inputstream. According to javadoc it seams that InputStreamReader "closes the stream" when reader.close() is invoked.

I'm not sure if ANY Reader must close its sources when you do reader.close(). I think that this is important so your code can use a reader no matter what concrete type it is.

Anyway it makes sense that it's enforced.