51

As per the java docs, invoking close() on any java.io Streams automatically invokes flush(). But I have seen in lot of examples, even in production codes, developers have explicitly used flush() just before close(). In what conditions we need to use flush() just before close()?

Siva Arunachalam
  • 7,582
  • 15
  • 79
  • 132
  • 1
    This question may help you a little bit [see this][1] [1]: http://stackoverflow.com/questions/7300676/when-to-use-flush-in-java – Chandra Sekhar Mar 25 '12 at 07:14
  • 9
    @Siva: `as per the Javadoc`. Quote and link, or it doesn't exist. As far as I know, *some* stream implementations will flush on close, while others won't. Do prove me wrong if that's not the case and the Javadoc says otherwise. – haylem Jul 27 '12 at 11:42
  • 4
    Same question as haylem. I read through Java API documentation of a few classes and some say that `flush()` is called in `close()` while others don't make any such comment. Any link? – Aseem Bansal Nov 06 '13 at 16:22

4 Answers4

32

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.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • 21
    redundant + pattern = anti-pattern? – Robino Jun 10 '15 at 16:38
  • 14
    Depending on the implenting class this might not be redundant. E.g if someinterface.getOutputStream() returns an OutputStream, you might not know if the close method calls flush or if the flush method is empty, if it's not explicitly documented. E.g. URLConnection.getOutputStream(): https://docs.oracle.com/javase/8/docs/api/java/net/URLConnection.html#getOutputStream-- – Puce Jul 16 '15 at 14:58
32

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.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
  • 5
    Upvoted. Anybody, actually, should not assume that all `close()` also invokes `flush()`. – Jin Kwon Aug 13 '16 at 04:10
  • 1
    @JinKwon They are perfectly entitled to do that for any output stream that extends `FilterOutputStream`: see the Javadoc. – user207421 Jul 02 '18 at 08:27
  • The statement "they don't know close() also invokes flush()" is misleading, it's *not* always the case. – Yann TM Jan 27 '23 at 14:13
11

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

Fabian
  • 3,310
  • 3
  • 26
  • 35
  • 1
    Both examples provided are essentially thin wrapper classes, so their `flush` and `close` implementations delegate to the underlying stream. I can't see how this alone could lead to any problems, as long as any "real" or buffering streams do flush when being closed. – vadipp Oct 07 '20 at 09:40
  • However I realize that the behavior is not (and can't be) enforced by the javadoc of `Closeable.close()`. – vadipp Oct 07 '20 at 09:44
4

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.

stackoverflowed
  • 686
  • 8
  • 22