Hello,
the CSR for read(char[],int,int) does not explicitly specify that "line
terminators are compressed into single newline ('\n') characters", as
the no-arg read() spec does.
Thus, it's not entirely clear what happens when the buffer is just large
enough to accept the \r in a \r\n sequence, potentially giving the
impression that this leaves a pending unread \n that might be counted
again in later invocations of either read() or read(char[],int,int).
It might be helpful to explicitly repeat the "compression" rule of the
no-arg read() even for read(char[],int,int).
Besides, the JDK 14 API states that the invocation
"Returns:
The number of *bytes* read, or -1 if the end of the stream has already
been reached"
I think it should say "characters" rather than "bytes" but perhaps this
has already been corrected.
Greetings
Raffaello
The CSR [2] has been approved so unless there are further comments I’ll push
this change [1] this week.
Thanks,
Brian
On Mar 19, 2020, at 7:43 AM, Brian Burkhalter <brian.burkhalter at oracle.com>
wrote:
Another webrev [1] which is adjusted from the previous one per the comments on
the CSR [2] is available for review. The only change is to the class-level
specification:
--- a/src/java.base/share/classes/java/io/LineNumberReader.java
+++ b/src/java.base/share/classes/java/io/LineNumberReader.java
@@ -41,7 +41,8 @@
*
* <p> A line is considered to be <a id="lt">terminated</a> by any one of a
* line feed ('\n'), a carriage return ('\r'), or a carriage return followed
- * immediately by a linefeed.
+ * immediately by a linefeed, or any of the previous terminators followed by
+ * end of stream, or end of stream not preceded by another terminator.
*
Thanks,
Brian
On Mar 13, 2020, at 10:28 AM, Brian Burkhalter <brian.burkhalter at oracle.com>
wrote:
An updated webrev is at [1] and a CSR has been filed [2].
[1] http://cr.openjdk.java.net/~bpb/8235792/webrev.02/
[2] https://bugs.openjdk.java.net/browse/JDK-8241020
