Why is System.out a PrintStream and not a PrintWriter?

I am trying to understand the difference between the PrintStream and PrintWriter.
I see that they have identical methods.

for instance,

void println(float x) Prints a floating-point number and then terminates the line.

Since System.out takes characters, for example when writing to the console, shouldn't it have been a PrintWriter instead of being a PrintStream?

System.out has been part of Java since version 1.0. PrintWriter was "only" added in version 1.1.

Stephan van Hulst wrote:System.out has been part of Java since version 1.0. PrintWriter was "only" added in version 1.1.

Thanks you

Also, System.out and System.in were at that time connected to operating-system entities which consisted of streams of bytes. I believe they still are for most operating systems where Java runs, in fact.

Anil Philip wrote:I am trying to understand the difference between the PrintStream and PrintWriter.
I see that they have identical methods.

They don't have identical methods. Specifically, methods of PrintStream do not throw IOException. PrintStream is more of a utility class (a hack) that is used primarily for System.in/out/err and has methods to print everything. PrintWriter, introduced later, otoh, is proper "Writer". You will notice other differences too in the JavaDoc.

Paul Anilprem wrote:They don't have identical methods. Specifically, methods of PrintStream do not throw IOException.

Neither do methods of PrintWriter.  The constructors of both PrintStream and PrintWriter throw IOException, but the methods do not.  

What's weird about both classes, though, is that while they extend OutputStream and Writer, you usually have no need to use most of the methods of those classes - except close(), maybe a few others.  But if you're using either PrintStream or PrintWriter, you want to use the various print() methods, not the various write() methods.  Note that those write() methods are where PrintStream and PrintWriter are actually different - but there's no good reason to use them.  I would say this is a design flaw.

Originally, the most important difference between PrintStream and PrintWriter was in the constructors.  A PrintStream could connect to OutputStreams, and a PrintWriter could connect to a Writer.  So you would choose one or the other depending on what you were connecting to.  However, over time, this difference diminished, as they added additional constructors to both classes to make it easier to connect either to whatever underlying stream/writer/file you want to.  Note that you can connect a PrintWriter to an OutputStream, but you can't connect a PrintStream to a Writer.  So far.

At this point, PrintWriter does everything you might want, and I would just use that wherever you can - except for System.out, which is still a PrintStream.  But usually, that difference will not matter.

Mike Simmons wrote:
Neither do methods of PrintWriter.  The constructors of both PrintStream and PrintWriter throw IOException, but the methods do not.  

You are right. I must have confused it with some other class.

Mike Simmons wrote:
Note that you can connect a PrintWriter to an OutputStream, but you can't connect a PrintStream to a Writer.  So far.

A PrintWriter is, after all, a Writer, while PrintStream is not. A Writer adds encoding logic on top of a raw byte stream, so connecting a PrintStream to a Writer would be like putting the cart before the horse.

It just occurred to me — and Paul touches on that — that a PrintWriter (as he says), has extra support logic and is sensitive to the data being printed. If memory serves, that includes keeping a buffer which is flushed when a newline is output, either directly (via println()) or as part of the data stream.

But System.out is directly affiliated with the Unix stdout and there are many, many programs which write non-text, that is, pure binary data to stdout. For example, a lot of video, audio, and image processing utilities. You never know when a JPEG being output might have a "0x0a" (newline) in the binary data, resulting in weird action.

So that's also an incentive not to use PrintWriter for System.out.

Both PrintStream and PrintWriter support auto-flush of the buffer, as an optional feature controlled by a boolean parameter at construction time.  On my MacBook Pro using OpenJDK 21, the System.out I see in the debugger comes with auto-flush enabled.  But I don't think that's a documented requirement - other systems may give you a System.out with auto-flush disabled.

After testing code in a debugger and investigating the source code, it looks like PrintStream is a lot more aggressive about auto-flush than PrintWriter is.  Calling just about any method on a PrintStream with auto-flush on seems to invoke flush() at (or very near) the end of the method call.  But for a PrintWriter with auto-flush on, it only auto-flushes when you call one of the println() methods.  Calling print() or write() doesn't auto-flush at all.  I suspect they decided they had gone a bit overboard with the initial auto-flush implementations in PrintStream, and used a milder version for PrintWriter - but were reluctant to change it in PrintStream, for fear of altering behavior of existing code.

Anyway, neither PrintStream nor PrintWriter seem to be changing data based on whether it looks like a newline character.   For PrintStream some methods do check for newline to decide whether to auto-flush or not. When a newline appears as part of an array of data, they simply pass it on unmolested, regardless of whether it's a "\n" or a "\r\n" or whatever - they just pass along what they are given.   But if you call one of the println() methods, those methods append a system-dependent newline to the end of whatever else they print.

So, I don't think the auto-flush or newline behavior would have any effect on a program's ability to write binary data.   What does have an effect, however, is the the character encoding used by PrintWriter.  Also the very API of a Writer is problematic, since it's all in char[] rather than byte[].  So yeah, Java programs still need some sort of OutputStream to write binary data to standard out.