classpath
[Top][All Lists]
Advanced

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

Re: java.io.DataInputStream.readLine misbehaviour


From: Mark Wielaard
Subject: Re: java.io.DataInputStream.readLine misbehaviour
Date: Thu, 06 Nov 2003 13:00:43 +0100

Hi,

On Sun, 2003-11-02 at 21:11, Guilhem Lavaux wrote:
> Mark Wielaard wrote:
> 
> >OK. Let me try to summarize the behavior we want so we can at least
> >create some good tests:
> >
> >DataInputStream.readLine():
> >- 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. ;-)

I assume you are talking about test/regression/InputStreamTest.java from
kaffe. I only briefly looked at it when the thread started and assumed
it was only some strange corner case since it was also using the
deprecated StringBufferInputStream (which has its own share of
problems). Does that test really show all the (corner) cases that were
discussed? (Especially when to wrapped InputStream is blocking just in
the middle of a \r\n pair. Which seems to be the tricky case.)

> 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().

That is interesting. So that implementation probably just does some
heuristics on the end of line if it can do it by looking ahead in the
stream, but not otherwise. That is a very sneaky thing todo, but
probably works in most cases that people care about. Sigh. What a bunch
of yuck needed for such an ugly and deprecated method.

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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