[jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF
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. ------------- Commit messages: - 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF Changes: https://git.openjdk.java.net/jdk17/pull/189/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=189&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6766844 Stats: 18 lines in 2 files changed: 12 ins; 1 del; 5 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
On Wed, 30 Jun 2021 23:00:24 GMT, Brian Burkhalter <bpb@openjdk.org> 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.
This PR supersedes PR [4591](https://github.com/openjdk/jdk/pull/4591). ------------- PR: https://git.openjdk.java.net/jdk17/pull/189
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&pr=189&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=189&range=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
On Fri, 2 Jul 2021 16:55:18 GMT, Brian Burkhalter <bpb@openjdk.org> 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
On Fri, 2 Jul 2021 16:50:11 GMT, Naoto Sato <naoto@openjdk.org> 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
On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter <bpb@openjdk.org> 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
On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter <bpb@openjdk.org> 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
On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter <bpb@openjdk.org> 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
On Fri, 2 Jul 2021 17:27:34 GMT, Joe Wang <joehw@openjdk.org> 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
On Fri, 2 Jul 2021 17:40:08 GMT, Brian Burkhalter <bpb@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
On Fri, 2 Jul 2021 18:43:36 GMT, Joe Wang <joehw@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
On Fri, 2 Jul 2021 19:08:09 GMT, Brian Burkhalter <bpb@openjdk.org> 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
On Fri, 2 Jul 2021 19:36:01 GMT, Joe Wang <joehw@openjdk.org> 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
On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter <bpb@openjdk.org> 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
On Wed, 30 Jun 2021 23:00:24 GMT, Brian Burkhalter <bpb@openjdk.org> 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.
This pull request has now been integrated. Changeset: f46a9172 Author: Brian Burkhalter <bpb@openjdk.org> URL: https://git.openjdk.java.net/jdk17/commit/f46a9172700a3e2d63cb772e604120bb6f... Stats: 18 lines in 2 files changed: 12 ins; 1 del; 5 mod 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF Reviewed-by: naoto, lancea, joehw ------------- PR: https://git.openjdk.java.net/jdk17/pull/189
participants (4)
-
Brian Burkhalter
-
Joe Wang
-
Lance Andersen
-
Naoto Sato