Do we really need to call flush() just before close() today?

Question

I read this question Using flush() before close() , and the accepted answer is this only means you follow the pattern.

Just like BufferedWriter#close() or FilterOutputStream.#close() , if all of buffered Stream/Writer will call its flush() when we call close() and if we (the dev and the dev who will review the code) all know the that, do we really still need this? If yes, what will be the reason?

Escapism

IMO, you don't, but this does not mean it's a good idea :-) if you switch from Writer or OutputStream implementation, you may end having unexpected behavior if you don't flush those that need it. You may argue that having some useless flush()'es is a bad JVM design, then my answer is "maybe" :-) Another thing that we may research is about backward compatibility, if previous versions of the JVM also work well without the flush(). – Picrotoxin

What exactly are you asking about, which is not covered by the question you're linking to? – Glutamate

@jarnbjo, I am just need to know if this is only an idled work execpt that this is only follow a rule explicitly? – Escapism

@Leo, would you please give us me an example in the answer that what will be the unexpected behavior if we switch to an OutputStream without muanlly flush() first ? – Escapism

@Jaskey maybe other classes implemented in other libraries that extends OutputStream but don't follow this "flush-on-close" contract that is stated in nowhere? :-) – Picrotoxin

Possible duplicate of BufferedWriter not writing everything to its output file – Destructionist

Answer 1

As the javadoc says, you don't need to flush yourself. But, it's still good to do, considering your readers, and common sense.

Few experts know the javadoc by heart. I wouldn't know for sure if the stream will be flushed or not without looking it up, and I'm probably not alone. Seeing the explicit flush() call makes this perfectly clear, and therefore makes the code easier to read.

Furthermore, the method name close() implies nothing about flushing. It's from the Closeable interface, and naturally, it says nothing about flushing. If you don't flush a buffered output stream before closing, despite wanting to flush it, you'll be relying on assumptions that may or may not be true. It would weaken your implementation.

Any assumptions you make, you should somehow pass on to future maintainers. One way to do that is by leaving a comment:

// no need to flush() manually, close() will do it automatically

If you don't leave this comment, future maintainers may have to lookup the javadoc too, if like me they don't have it memorized. But then, why would you write such comment when it's easier and better to just call it yourself now and be done with it.

In short, flushing first before closing is simply following good logic. No need for assumptions and second guesses, and no need to make your readers think.

Sabec

Two more things to be clear.1.Only buffrered stream needs flush() before close() 2.Every stream in java.io will not have any side effect if I close() without flush(). Is it right? – Escapism

1. Yes, flushing is a concept specific to buffered output. See also Flushable 2. There are quite a few streams in java.io. I'd have to go through all of them to verify, and I just don't see the point in doing so. On the other hand, I added one more reason to flush, see my updated answer. – Sabec

Answer 2

For output, it is important that we do call flush() and close() because buffered data could be lost, as explained by the first answer here. If your program's output is smalland your writer finishes quickly, it won't make much difference to close() and flush() in my experience.

For input, it won't matter if we don't call close() before the system exits.

Guitar

But the close() already flush for us, so this is my question that why do we need to flush manually right before close() – Escapism

I have never had to do that before, not sure why you would. – Guitar