A DESCRIPTION OF THE PROBLEM :
This is basically a clone ofJDK-4140318. It appears the test code was understood incorrectly and therefore the evalutation was incorrect.
The return value of Reader.ready() is described as:
"True if the next read() is guaranteed not to block for input"
However, if a call to LineNumberReader.read() just compressed \r\n (i.e. skipLF was set to true) then ready() will incorrectly return true even though a subsequent call to read() may block.
The reason for this is that if read() encounters a \n it will discard it, since it has been compressed and therefore will try to read a second character.
This is basically a clone of
The return value of Reader.ready() is described as:
"True if the next read() is guaranteed not to block for input"
However, if a call to LineNumberReader.read() just compressed \r\n (i.e. skipLF was set to true) then ready() will incorrectly return true even though a subsequent call to read() may block.
The reason for this is that if read() encounters a \n it will discard it, since it has been compressed and therefore will try to read a second character.
- relates to
-
JDK-8230344 LineNumberReader.skipLF is not considered by all methods
-
- Open
-
-
JDK-8230342 LineNumberReader.getLineNumber() returns inconsistent results after EOF
-
- Resolved
-
-
JDK-8230343 LineNumberReader.read(char[] cbuf, int off, int len) sets skipLF
-
- Open
-