Hi Chris,
Is it really impossible to specify at least that closing the stream will
terminate the read?
A thread that is blocking on some I/O needs to have some way to
interrupt it.
Terminating the VM because a read is stuck or to leave the thread around
indefinately is too severe.
+ * <p> The behavior for the case where the input stream is
<i>asynchronously
+ * closed</i>, or the thread interrupted during the read, is highly
input
+ * stream specific, and therefore not specified.
+ *
Roger
On 5/7/2015 10:10 AM, Chris Hegarty wrote:
Thanks for the comments. All have been considered and incorporated ( where
applicable ).
I sketched out a readAllBytes, added some basic tests, and moved this into a
webrev. I have not created a specdiff, as the changes simply add two new
methods, that are easily readable.
I think this version, less review comments, covers the most common use-cases.
http://cr.openjdk.java.net/~chegar/readBytes/webrev.00/
-Chris.
On 5 May 2015, at 10:54, Alan Bateman <alan.bate...@oracle.com> wrote:
On 02/05/2015 09:27, Chris Hegarty wrote:
:
Thanks, this was an editing issue. Removed.
I think the javadoc looks quite good now, except may be the first statement "Reads some bytes
...". It might be clearer to start with "Reads a given number of bytes ...". The
subsequent text makes the short read case and the return value clear.
As Alan has commented, another readAllBytes() returning a byte[] maybe useful
too ( but a different use case ). Let’s park this momentarily, while I sketch
up the readAllBytes variant, so we can ensure that the typical use cases have
been addressed. Doing so may feedback into the spec of this method. I’ll push
this latest draft into the sandbox so it is not lost.
Yes, a separate use-case but once that I would expect to be common.
-Alan.
