[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