P4
FULL PRODUCT VERSION :
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.10240]
A DESCRIPTION OF THE PROBLEM :
When reading a file with an empty line at the end, BufferedReader.readLine() returns null instead of returning an empty line.
Because of this bug, there is no way to tell if the original file had a trailing empty line or not.
Consider the following two example files:
File 1 : "Single line of text.[EOF]"
File 2 : "Single line of text followed by empty line.\n[EOF]"
For File 1, I would expect successive calls to readLine() to return "Single line of text." and null.
For File 2, I would expect successive calls to readLine() to return "Single line of text followed by empty line." , "" and then null.
This makes sense to me since there is in fact one last line with nothing on it. Just like any other empty line, the fact that the file ends with \n[EOF] implies there is an emtpy string between the two delimiters: \n<empty string>[EOF]
This is the same as: \n\n -> \n<empty string>\n
Reporting a null early is incorrect and is the reason why many programmers rely on other libraries such as IOUtils from Apache to work around the issue.
I've marked this issue as severe because I consider the fact as having to use another library as a "difficult to make progress" kind of issue.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create two files, one with a training empty line and the other without.
2. Create test cases for each file, with first one expecting an explicit empty line at the end of the file before the null on EOF.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Whenever there is an empty line at end of file, we should be getting an empty string before the null.
\n<empty string>[EOF]
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
The workaround I've been using for years is either manually scanning delimiters or using Apache IOUtils.
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.10240]
A DESCRIPTION OF THE PROBLEM :
When reading a file with an empty line at the end, BufferedReader.readLine() returns null instead of returning an empty line.
Because of this bug, there is no way to tell if the original file had a trailing empty line or not.
Consider the following two example files:
File 1 : "Single line of text.[EOF]"
File 2 : "Single line of text followed by empty line.\n[EOF]"
For File 1, I would expect successive calls to readLine() to return "Single line of text." and null.
For File 2, I would expect successive calls to readLine() to return "Single line of text followed by empty line." , "" and then null.
This makes sense to me since there is in fact one last line with nothing on it. Just like any other empty line, the fact that the file ends with \n[EOF] implies there is an emtpy string between the two delimiters: \n<empty string>[EOF]
This is the same as: \n\n -> \n<empty string>\n
Reporting a null early is incorrect and is the reason why many programmers rely on other libraries such as IOUtils from Apache to work around the issue.
I've marked this issue as severe because I consider the fact as having to use another library as a "difficult to make progress" kind of issue.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create two files, one with a training empty line and the other without.
2. Create test cases for each file, with first one expecting an explicit empty line at the end of the file before the null on EOF.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Whenever there is an empty line at end of file, we should be getting an empty string before the null.
\n<empty string>[EOF]
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
The workaround I've been using for years is either manually scanning delimiters or using Apache IOUtils.