Java Reference
In-Depth Information
As well as the usual
write()
,
flush()
, and
close()
methods,
PrintStream
has 9 over‐
loaded
print()
methods and 10 overloaded
println()
methods:
public
void
print
(
boolean
b
)
public
void
print
(
char
c
)
public
void
print
(
int
i
)
public
void
print
(
long
l
)
public
void
print
(
float
f
)
public
void
print
(
double
d
)
public
void
print
(
char
[]
text
)
public
void
print
(
String
s
)
public
void
print
(
Object
o
)
public
void
println
()
public
void
println
(
boolean
b
)
public
void
println
(
char
c
)
public
void
println
(
int
i
)
public
void
println
(
long
l
)
public
void
println
(
float
f
)
public
void
println
(
double
d
)
public
void
println
(
char
[]
text
)
public
void
println
(
String
s
)
public
void
println
(
Object
o
)
Each
print()
method converts its argument to a string in a predictable fashion and
writes the string onto the underlying output stream using the default encoding. The
println()
methods do the same thing, but they also append a platform-dependent line
separator to the end of the line they write. This is a linefeed (
\n
) on Unix (including
Mac OS X), a carriage return (
\r
) on Mac OS 9, and a carriage return/linefeed pair (
\r
\n
) on Windows.
PrintStream
is evil and network programmers should avoid it like the
plague!
The first problem is that the output from
println()
is platform dependent. Depending
on what system runs your code, lines may sometimes be broken with a linefeed, a car‐
riage return, or a carriage return/linefeed pair. This doesn't cause problems when writing
to the console, but it's a disaster for writing network clients and servers that must follow
a precise protocol. Most network protocols such as HTTP and Gnutella specify that
lines should be terminated with a carriage return/linefeed pair. Using
println()
makes
it easy to write a program that works on Windows but fails on Unix and the Mac.
Although many servers and clients are liberal in what they accept and can handle in‐
correct line terminators, there are occasional exceptions.
The second problem is that
PrintStream
assumes the default encoding of the platform
on which it's running. However, this encoding may not be what the server or client
expects. For example, a web browser receiving XML files will expect them to be encoded
