Re: [patch] "\r\n" handling in DataInputStream.readLine()

[Per Bothner <bothner@pacbell.net>]

I have mixed feelings about this situation.

The correct solution is to use a flag indicating if the previous byte was
a '\r'.  However, if we are going to do that, we might as well do it
correctly, and change the various read methods to check the flag.  (We
can do some minor optimization by replacing read() by in.read().)

However, I think it is quite reasonable to leave things as is.  The
readLine() method is inherently bogus in its design - which is why it has
been deprectated.  DataInputStream is for *binary* I/O.  A method like
readLine make no sense in that context:  You can't fiddle with unknown EOL
conventions in the middle of a file of binary data.  People should not
be using it.  (If they do use it, they should be using a BufferedInputStream.)

So the question is:  How important it it to implement deprecated methods
fully against a buggy spec?  Is it worth a minor slowdown?

Note if we leave the code as is, I think there is still a bug:  The tests
for  (read() & 0xFF) != '\n' will do the wrong thing on EOF.
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/