Feedback is on webrev.02 http://cr.openjdk.java.net/~chegar/7000511/webrev.02/webrev/ :
* PrintStream - .flush(), close(), most println() methods synchronize on this for their entire implementation. They could just be made synchronized methods. - The javadoc for append(CharSequence,int,int) for the csq==null condition seems misleading as start and end are considered. * Formatter - The zero params constructor could just call this((Apppendable) null). The advantage is that the StringBuilder is only constructed in one place. - The Formatter(Locale) constructor could just call this(l, (Apppendable) null). Same reason. On Dec 14 2010, at 07:07 , 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.
