[15] 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF
Brian Burkhalter
brian.burkhalter at oracle.com
Wed Jul 22 18:36:06 UTC 2020
Hello,
> On Jul 22, 2020, at 4:52 AM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
>
> 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).
Yes, I think that the sentence
+ * <a href="#lt">Line terminators</a> are compressed into single newline
+ * ('\n') characters.
should be added to the specs of read(char[],int,int) and readLine(), or some equivalent statement be added to the class level doc.
> 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.
No, it has not been correct and I agree that it should be “characters,” not “bytes.”
Thanks,
Brian
More information about the core-libs-dev
mailing list