Chris Hegarty wrote:
Failing java.io.PrintStream, java.io.PrintWriter, java.util.Scanner,
and java.util.Formatter multi-arg constructors that take a
java.io.File or String filename (as well as one or more additional
args) opens a FileIn/OutputStream to the given File/filename. If one
of the other given args causes the constructor to fail ( null or
unsupported charset for example ) the FileIn/OutputStream is never
closed, and the application does not have a reference to it. You rely
on the finalizer to close the stream.
This is most serious on Windows because you cannot remove a file if
there is an open handle to it.
I also cleaned up an existing regression test that fails in samevm
mode (partly) because of this. And removed another excluded test from
the list since its bug was fixed some time ago.
Webrev:
http://cr.openjdk.java.net/~chegar/7000511/webrev.00/webrev/
-Chris.
It would be good to get this one fixed. If I understand the proposal
correctly, there may still be side effects when NPE or
UnsupportedEncodingException is thrown. When I say "side effects" I mean
that an empty file may be created or an existing file truncated before
the exception is thrown. I wonder you've tried to extend the list of
parameters to the private constructors to avoid this. A
toCharset(String) method should be used to lookup the Charset for
example rather than having OutputStreamWriter to do it.
One minor comment is that I see that PrintStream is using
java.util.Objects. Nice to see it being used but I wonder about loading
yet another class during startup (System.out and err are PrintStreams
and are initialized early in the startup).
-Alan
