[jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

Brian Burkhalter bpb at openjdk.java.net
Fri Jul 2 19:10:51 UTC 2021


On Fri, 2 Jul 2021 18:43:36 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> 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.

Thanks for the suggestion. I am happy with it as is, but I'll hold off integrating it for now and rethink it later.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/189


More information about the core-libs-dev mailing list