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().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 :)
I'll be quite busy for the next few days. But if nobody takes the job, I'll do it asap.
Cheers, Guilhem.
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
