Using flush() before close()

Developer get into a habit of calling flush() after writing something which must be sent.

IMHO Using flush() then close() is common when there has just been a write e.g.

// write a message
out.write(buffer, 0, size);
out.flush();

// finished
out.close();

As you can see the flush() is redundant, but means you are following a pattern.

I guess in many cases it's because they don't know close() also invokes flush(), so they want to be safe.

Anyway, using a buffered stream should make manual flushing almost redundant.

I want to point out an important concept that many previous comments have alluded to:

A stream's close() method does NOT necessarily invoke flush().

For example org.apache.axis.utils.ByteArray#close() does not invoke flush().
(click link to see source code)

The same is true more generally for any implementations of Flushable and Closeable. A prominent example being java.io.PrintWriter. Its close() method does NOT call flush().
(click link to see source code)

This might explain why developers are cautiously calling flush() before closing their streams. I personally have encountered production bugs in which close() was called on a PrintWriter instance without first calling flush().

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.