Streams - Java Network Programming - page 44

public final void readFully ( byte [] input , int offset , int length )
throws IOException
Finally, DataInputStream provides the popular readLine() method that reads a line of
text as delimited by a line terminator and returns a string:
public final String readLine () throws IOException
However, this method should not be used under any circumstances, both because it is
deprecated and because it is buggy. It's deprecated because it doesn't properly convert
non-ASCII characters to bytes in most circumstances. That task is now handled by the
readLine() method of the BufferedReader class. However, that method and this one
share the same insidious bug: they do not always recognize a single carriage return as
ending a line. Rather, readLine() recognizes only a linefeed or a carriage return/linefeed
pair. When a carriage return is detected in the stream, readLine() waits to see whether
the next character is a linefeed before continuing. If it is a linefeed, the carriage return
and the linefeed are thrown away and the line is returned as a String . If it isn't a linefeed,
the carriage return is thrown away, the line is returned as a String , and the extra char‐
acter that was read becomes part of the next line. However, if the carriage return is the
last character in the stream, then readLine() hangs, waiting for the last character, which
isn't forthcoming.
This problem isn't obvious when reading files because there will almost certainly be a
next character: -1 for end of stream, if nothing else. However, on persistent network
connections such as those used for FTP and late-model HTTP, a server or client may
simply stop sending data after the last character and wait for a response without actually
closing the connection. If you're lucky, the connection may eventually time out on one
end or the other and you'll get an IOException , although this will probably take at least
a couple of minutes, and cause you to lose the last line of data from the stream. If you're
not lucky, the program will hang indefinitely.
Readers and Writers
Many programmers have a bad habit of writing code as if all text were ASCII or at least
in the native encoding of the platform. Although some older, simpler network protocols,
such as daytime, quote of the day, and chargen, do specify ASCII encoding for text, this
is not true of HTTP and many other more modern protocols, that allow a wide variety
of localized encodings, such as KOI8-R Cyrillic, Big-5 Chinese, and ISO 8859-9 for
Turkish. Java's native character set is the UTF-16 encoding of Unicode. When the en‐
coding is no longer ASCII, the assumption that bytes and chars are essentially the same
things also breaks down. Consequently, Java provides an almost complete mirror of the
input and output stream class hierarchy designed for working with characters instead
of bytes.