RFR [9] Add blocking bulk read to java.io.InputStream

Roger Riggs Roger.Riggs at Oracle.com
Thu May 7 14:20:47 UTC 2015


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




More information about the core-libs-dev mailing list