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
 
-