JDK-8230345 : LineNumberReader.ready() can return true despite read() blocking
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 11.0.4,13,14
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_10
  • CPU: x86_64
  • Submitted: 2019-08-27
  • Updated: 2019-08-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8230344 - LineNumberReader.skipLF is not considered by all methods
Relates :  
JDK-8230343 - LineNumberReader.read(char[] cbuf, int off, int len) sets skipLF
Relates :  
JDK-8230342 - LineNumberReader.getLineNumber() returns inconsistent results after EOF
Description
A DESCRIPTION OF THE PROBLEM :
This is basically a clone of JDK-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.