[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: misbehaviour

From: Guilhem Lavaux
Subject: Re: misbehaviour
Date: Sun, 02 Nov 2003 21:11:53 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030428

Mark Wielaard wrote:

OK. Let me try to summarize the behavior we want so we can at least
create some good tests:

- Should not block when it has seen at least a \r but return as soon as
 possible even when it cannot be sure that the next character is or
 isn't a \n to prevent programs from blocking/deadlocking.
- If there is a unconsumed \n in the stream right after a readLine()
 then that \n should be transparently consumed for all these cases:
 - readLine() is called again.
 - another DataInputStream read method is called.
 - a non-overridden (Filter)InputStream is called.
 - a method in the originally wrapped InputStream is called.

That will be an ugly nut to crack. Especially how to guarantee that last
requirement is nasty. And the method is (rightly) deprectated since
programmers should BufferedReader.readLine() anyway (specified since
1.1). Sigh.

But having a good test case will be very valuable start.
Any volunteers :)
Well ! You described entirely the behaviour of the test. So it should be considered as done. ;-) But JDK won't pass this test (I've just tested one or two pieces of the ideas). Actually if DataInputStream can detect the '\n' it eats it directly in the call to readLine(). I'll be quite busy for the next few days. But if nobody takes the job, I'll do it asap.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]