I was having a look at this tutorial at Sun on command line I/O. It stated that:
You might expect the Standard Streams to be character streams, but, for historical reasons, they are byte streams. System.out and System.err are defined as PrintStream objects. Although it is technically a byte stream, PrintStream utilizes an internal character stream object to emulate many of the features of character streams.
Does any one know what "the historical reasons" are?
I would guess that the reason is to be backwards-compatible with POSIX C/C++ standard I/O, in which stdin, stdout, and stderr (the C/C++ equivalent of System.in, System.out, and System.err respectively) are byte streams. In Windows, those streams perform CRLF translation, but in POSIX systems, no such conversions occur, and you can freely read and write non-character binary data. Lots of Unix utilities do this, such as GNU's gzip and tar.
Remember that characters in Java use a 16 bit Unicode character. The original System.in etc needed to be compatible with the environments which supported Java, which (back then at the Dawn of Time) often didn't support Unicode. That, along with the annoyingly disparate treatment of line ends, meant that byte streams were the only type that had the same semantics no matter what platform.
The "historical reasons" are that character streams did not exist in Java 1.0. Apparently Sun realized that the character translation model was insufficient and the Character oriented Reader/Writer class hierarchy was added in Java 1.1.
But it was too late for System.out and friends.