Am 01/08/17 um 05:20 schrieb Tibor Digana:
> There is also no reason to close a stream twice due to the close() is in
> finally does always the close.
> No reason to call close() and resource= null before *} finally {* and call
> close() within *finally *the second time.It's not called twice. That's the purpose of setting the resource to null. The only intention there is a finally block is to clean up on failure to not leak open resources *on failure*. > > *ConsoleOutputFileReporter.java is missing flush at L69 because of > FileOutputStream.close() which does not implicitly flush.* No need to flush there as well because there is nothing to flush. FileOutputStream does not perform any buffering. This is the Javadoc of the java.io.Flushable interface: "Flushes this stream by writing any buffered output to the underlying stream." If there is no buffer, flush becomes a no-op. > > I disagree about relying on implicit flushing in every IO implementation. You need to rely on the classes in the java.io package or you need to roll your own. > *PrintStream and BufferedWriter should make flush on close.PrintWrite and > FileOutputStream do not flush on close.* Because they do not perform any buffering. Take a look at the close and flush methods in class OutputStream. They are no-ops when not overridden. FileOutputStream does not override flush and inherits it as a no-op because there is no buffer to flush. PrintStream does call flush on close by calling close on the delegate. We really are discussing Java fundamentals already. > > In case of *PrintStream *and *BufferedWriter *it is however written in > Javadoc that close() is done by flushing as well but it is not implemented > in such way. Of course it is. If not, create a reproducible test case and report a bug against the JDK. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
