[jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
Joe Wang
joehw at openjdk.java.net
Fri Jul 2 18:46:53 UTC 2021
On Fri, 2 Jul 2021 17:40:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
>> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 161:
>>
>>> 159: * Unlike the {@link InputStream#read(byte[],int,int) overridden method}
>>> 160: * of {@code InputStream}, this method returns {@code -1} instead of zero
>>> 161: * if the end of the stream has been reached and {@code len == 0}.
>>
>> The statement "return -1 if the end of the stream has been reached and len == 0" gives an impression that it requires both conditions to be met: end of the stream && len==0, but the tests show -1 is expected if len == 0 without an attempt to read the stream.
>>
>> The overridden method stated that "If len is zero, then no bytes are read and 0 is returned", the above note looks like was meant for this statement since the overridden method also return -1 if the stream is at end of file.
>
> Both conditions of the statement are intended to be met. If the stream is at its end then
>
> if (pos >= count) {
> return -1;
> }
>
> will cause `-1` to be returned because at end of stream the condition `pos >= count` is met.
>
> The overridden method always returns `0` if `len == 0`.:
>
>
> public int read(byte b[], int off, int len) throws IOException {
> Objects.checkFromIndexSize(off, len, b.length);
> if (len == 0) {
> return 0;
> }
Right. I understand. The intention was, unlike the overridden method that returns 0 if len == 0 and -1 if at the end of the stream, this method returns -1 in both cases. A careful reader, after comparing both methods, would understand correctly that the difference is in the case of "len==0". I'm fine if you think this is good enough. Just a thought though that the statement could be interpreted as if both conditions need to be met at the same time (if "and" is taken as "&&", e.g. if (pos>==count && len==0) ).
Something like the following might be clearer?
* Unlike the {@link InputStream#read(byte[],int,int) overridden method}
* of {@code InputStream} that returns {@code -1} if the end of the stream
* has been reached and {@code 0} if {@code len == 0}, this method returns
* {@code -1} in both cases.
Just my 2 cents.
-------------
PR: https://git.openjdk.java.net/jdk17/pull/189
More information about the core-libs-dev
mailing list