The answers already provided give interesting insights that I will try to compile here.

Closeable and Flushable being two independent traits, Closeable do not specify that close() should call flush(). This means that it is up to the implementation's documentation (or code) to specify whether flush() is called or not. In most cases it is the norm, but there is no guaranty.

Now regarding what @Fabian wrote: It is true that java.io.PrintWriter's close() method does not call flush(). However it calls out.close() (out being the underlying writer). Assuming out is a BufferedWriter, we are fine since BufferedWriter.close() is flushing (according to it's doc). Had it be another writer, it may not have been the case...

So you have two choices:

• either you ensure that at least one inner Writer/Stream flushes by itself (beware in case of code refactoring),
• or you just call flush() and you're on the safe side all the time.

Solution 2, requiring less work, is my preferred one.

The answers already provided give interesting insights that I will try to compile here.

Closeable and Flushable being two independent traits, Closeable do not specify that close() should call flush(). This means that it is up to the implementation's documentation (or code) to specify whether flush() is called or not. In most cases it is the norm, but there is no guaranty.

Now regarding what @Fabian wrote: It is true that java.io.PrintWriter's close() method does not call flush(). However it calls out.close() (out being the underlying writer). Assuming out is a BufferedWriter, we are fine since BufferedWriter.close() is flushing (according to its doc). Had it be another writer, it may not have been the case...

So you have two choices:

• either you ensure that at least one inner Writer/Stream flushes by itself (beware in case of code refactoring),
• or you just call flush() and you're on the safe side all the time.

Solution 2, requiring less work, is my preferred one.