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.
*ConsoleOutputFileReporter.java is missing flush at L69 because of
FileOutputStream.close() which does not implicitly flush.*
I disagree about relying on implicit flushing in every IO implementation.
Flush is not called within every close() method of every I/O
implementation. I checked the JRE implementation and Javadoc.
About which Java class are you talking about?
According to the Javadoc (*implementation might be buggy*):
*PrintStream and BufferedWriter should make flush on close.PrintWrite and
FileOutputStream do not flush on close.*
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. Therefore I would not rely on it, and because of different
bugs in JRE between vendors I would not rely either.
As a real example of maybe JRE bug:
*PrintStream#close()*
calls
*BufferedWriter#close()*
which calls internal method
*flushBuffer()* but the problem is that this internal method *flushBuffer()*
does not flush the delegate stream
and the Javadoc says interesting things (*without** flushing the stream
itself*):
(it is writing char[] buffer to delegate stream, which is what Oracle means
a kind of flush, but not flushing in real)
/**
* Flushes the output buffer to the underlying character stream,
*without** * flushing the stream itself*. This method is non-private
only so that it
* may be invoked by PrintStream.
*/
void flushBuffer() throws IOException {
synchronized (lock) {
ensureOpen();
if (nextChar == 0)
return;
*out.write(cb, 0, nextChar);*
nextChar = 0;
}
}
/**
* Flushes the stream.
*
* @exception IOException If an I/O error occurs
*/
public void flush() throws IOException {
synchronized (lock) {
flushBuffer();
*out.flush();*
}
}
On Sun, Jan 8, 2017 at 3:49 AM, Christian Schulte [via Maven] <
[email protected]> wrote:
> Am 01/08/17 um 03:28 schrieb Tibor Digana:
> > As an example flush() is missing in RunEntryStatisticsMap.java L130.
> > Maybe I would find more but this is not the only case. There are 24
> files
> > changed.
>
> It's not missing there. Close is guaranteed to perform a flush implicitly.
>
> resource.flush();
> resource.close();
>
> The flush really is not needed. If removing a call to the flush method
> introduces an issue, the real issue really is a missing call to close.
> There seems to be one case for which an IT is failing now. The IT is
> forcing an OutOfMemoryError and due to missing flush calls, some file is
> empty or not even created at all, because that error isn't handled
> correctly (there somewhere is a missing finally block to ensure open
> resources are cleaned up correctly). No flush -> OutOfMemoryError -> no
> call to close anywhere so no flushes performed.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5891905&i=0>
> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5891905&i=1>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Lets-talk-about-our-
> changes-openly-maven-surefire-git-commit-SUREFIRE-1324-
> Surefire-incorrectly-supp-tp5891058p5891905.html
> To start a new topic under Maven Developers, email
> [email protected]
> To unsubscribe from Maven Developers, click here
> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
> .
> NAML
> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context:
http://maven.40175.n5.nabble.com/Lets-talk-about-our-changes-openly-maven-surefire-git-commit-SUREFIRE-1324-Surefire-incorrectly-supp-tp5891058p5891924.html
Sent from the Maven Developers mailing list archive at Nabble.com.
