JDK-4988954 : (fmt) Print{Stream,Writer} flushing behaviour is inconsistent
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-02-04
  • Updated: 2017-05-16
  • Resolved: 2004-07-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 b59Fixed
Description
The new Print{Stream,Writer} convenience constructors added for formatting
are inconsistent with respect to flushing.  All state that there is no
automatic line flushing; however, this likely not what's actually implemented.

From ###@###.###:

Stream flushing is a little odd.   PrintWriter only flushes when a newline is
written, so

  PrintWriter.printf("Hello");

should *not* autoflush, while one can argue that

  PrintStream.printf("Hello");

*should* autoflush because

  PrintStream.print("Hello");

does.

The flushing behavior in these classes is weird and inconsistent, but we 
need to try to not introduce any more.

PrintWriter class doc goes out of its way to point out how its flushing 
behavior is different from PrintStream's.

In an ideal world, we would want, for any output stream s,

changing

  s.print("foo")
to
  s.printf("foo")

and

  s.println("foo")
to
  s.printf("foo%n")

should have no observable effect, including with regard to stream flushing.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-rc FIXED IN: tiger-rc INTEGRATED IN: tiger-b59 tiger-rc
2004-09-08

EVALUATION This issue needs to be resolved before we ship tiger. -- iag@sfbay 2004-02-04 Actually, PrintStream.print("Hello") doesn't autoflush. PrintStream.print("Hello\n") will autoflush. For output stream s = PrintStream: The flushing behaviour of format/printf can be made consistent with existing methods on PrintStream by ignoring the autoflush field and allowing the internal write methods on PrintStream to handle flushing as necessary based on the content of the data being written. All we need to do is remove the autoflush tests: *************** *** 897,904 **** || (formatter.locale() != Locale.getDefault())) formatter = new Formatter((Appendable) this); formatter.format(Locale.getDefault(), format, args); - if (autoFlush) - out.flush(); } } catch (InterruptedIOException x) { Thread.currentThread().interrupt(); --- 897,902 ---- *************** *** 956,963 **** || (formatter.locale() != l)) formatter = new Formatter(this, l); formatter.format(l, format, args); - if (autoFlush) - out.flush(); } } catch (InterruptedIOException x) { Thread.currentThread().interrupt(); The remaining specification in this class requires no changes. For output stream s = PrintWriter: PrintWriter controls flushing based upon the methods that are called (rather than whether a new line happens to appear in the output). Therefore, the implementation of format/printf with respect to autoflusing is reasonable if these new methods are given the same status as println. For this class, we must update the specification of PrintWriter to include format/printf in the list of methods which autoflush. For completeness, we should also add documentation to format/printf indicating that they autoflush. Note that for PrintWriter it's hard to achieve the idea-world result of making PrintWriter.printf("Hello%n") the same as PrintWriter.println("Hello") because we do that, one can also ask why PrintWriter.print("Hello\n") doesn't autoflush the same way. Unfortunately, the latter is existing behaviour which we can not change due to compatibilty constraints. For the new Print{Stream,Writer} contructors, I have verified that the setting of autoflush is consistent with pre-existing constructors which don't take the autoflush parameter. The current implementation matches the specification. No changes are necessary in this area. -- iag@sfbay 2004-06-20
2004-06-20