Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
On Fri, 2 Jul 2021 19:36:01 GMT, Joe Wang wrote: >> Thanks for the suggestion. I am happy with it as is, but I'll hold off >> integrating it for now and rethink it later. > > Ok, good to know. Have a great weekend! I am inclined to leave the wording alone barring serious objections to the contrary. - PR: https://git.openjdk.java.net/jdk17/pull/189
Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
On Fri, 2 Jul 2021 19:08:09 GMT, Brian Burkhalter wrote:
>> 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.
Ok, good to know. Have a great weekend!
-
PR: https://git.openjdk.java.net/jdk17/pull/189
Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter wrote: >> Modify the specification of >> `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is >> returned instead of `0` when the stream is at its end and the third >> parameter, `len`, is zero. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 6766844: Correct error messages in test Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/189
Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
On Fri, 2 Jul 2021 18:43:36 GMT, Joe Wang 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
Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
On Fri, 2 Jul 2021 17:40:08 GMT, Brian Burkhalter 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
Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
On Fri, 2 Jul 2021 17:27:34 GMT, Joe Wang wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 6766844: Correct error messages in test
>
> 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;
}
-
PR: https://git.openjdk.java.net/jdk17/pull/189
Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter wrote:
>> Modify the specification of
>> `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is
>> returned instead of `0` when the stream is at its end and the third
>> parameter, `len`, is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 6766844: Correct error messages in test
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.
-
PR: https://git.openjdk.java.net/jdk17/pull/189
Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter wrote: >> Modify the specification of >> `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is >> returned instead of `0` when the stream is at its end and the third >> parameter, `len`, is zero. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 6766844: Correct error messages in test Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/189
Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter wrote: >> Modify the specification of >> `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is >> returned instead of `0` when the stream is at its end and the third >> parameter, `len`, is zero. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 6766844: Correct error messages in test Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/189
Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
On Fri, 2 Jul 2021 16:50:11 GMT, Naoto Sato wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 6766844: Correct error messages in test
>
> test/jdk/java/io/ByteArrayInputStream/ReadAllReadNTransferTo.java line 57:
>
>> 55: }
>> 56: if (bais.read(new byte[1], 0, 0) != -1) {
>> 57: throw new RuntimeException("read(byte[],int,int) did not
>> return 0");
>
> Should these exception messages be "did not return -1"?
Oh you are correct. Thanks!
-
PR: https://git.openjdk.java.net/jdk17/pull/189
Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
On Fri, 2 Jul 2021 16:55:18 GMT, Brian Burkhalter wrote:
>> Modify the specification of
>> `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is
>> returned instead of `0` when the stream is at its end and the third
>> parameter, `len`, is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 6766844: Correct error messages in test
test/jdk/java/io/ByteArrayInputStream/ReadAllReadNTransferTo.java line 57:
> 55: }
> 56: if (bais.read(new byte[1], 0, 0) != -1) {
> 57: throw new RuntimeException("read(byte[],int,int) did not
> return 0");
Should these exception messages be "did not return -1"?
-
PR: https://git.openjdk.java.net/jdk17/pull/189
Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]
> Modify the specification of > `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is > returned instead of `0` when the stream is at its end and the third > parameter, `len`, is zero. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 6766844: Correct error messages in test - Changes: - all: https://git.openjdk.java.net/jdk17/pull/189/files - new: https://git.openjdk.java.net/jdk17/pull/189/files/5b89ab60..528afc5f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17=189=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17=189=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/189.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/189/head:pull/189 PR: https://git.openjdk.java.net/jdk17/pull/189
