On 20/05/15 15:17, Alan Bateman wrote:
On 14/05/2015 09:26, Chris Hegarty wrote:
I think we’ve agreed that we are not going to attempt to re-introduce
the problematic interruptible I/O mechanism. These new methods are
targeted at specific use-cases and common patterns found in code. I’d
like to
On 14/05/2015 09:26, Chris Hegarty wrote:
I think we’ve agreed that we are not going to attempt to re-introduce the
problematic interruptible I/O mechanism. These new methods are targeted at
specific use-cases and common patterns found in code. I’d like to do a final
review of the spec before
I think we’ve agreed that we are not going to attempt to re-introduce the
problematic interruptible I/O mechanism. These new methods are targeted at
specific use-cases and common patterns found in code. I’d like to do a final
review of the spec before finalising it.
http://cr.openjdk.java.net
On 07/05/2015 15:36, Roger Riggs wrote:
Hi Alan,
I recognize that this utility function can't compensate for failings
of the underlying
stream. But I thought async close was the one common action that did
work on streams
to avoid indefinite blocking.
No, not generally for InputStreams so it
Hi Alan,
I recognize that this utility function can't compensate for failings of
the underlying
stream. But I thought async close was the one common action that did
work on streams
to avoid indefinite blocking.
It would be more appropriate to say that the behavior depends on the
underlying
On 07/05/2015 15:20, Roger Riggs wrote:
Hi Chris,
Is it really impossible to specify at least that closing the stream
will terminate the read?
The wording that Chris has is wording that we use elsewhere too. In
general then the InputStream could be to anything and no guarantee that
all Input
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.
+ * T
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
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
Thanks for looking at this Roger.
On 1 May 2015, at 15:20, Roger Riggs wrote:
> Hi Chris,
>
> There is some duplication in the descriptions of the buffer contents; see
> below.
>
> On 5/1/2015 5:54 AM, Chris Hegarty wrote:
>> This latest version addresses all comments so far:
>>
>> /**
>>
Hi Chris,
There is some duplication in the descriptions of the buffer contents;
see below.
On 5/1/2015 5:54 AM, Chris Hegarty wrote:
This latest version addresses all comments so far:
/**
* Reads some bytes from the input stream into the given byte array. This
* method blocks until {@code
This latest version addresses all comments so far:
/**
* Reads some bytes from the input stream into the given byte array. This
* method blocks until {@code len} bytes of input data have been read, end
* of stream is detected, or an exception is thrown. The number of bytes
* actually read, po
On 23 Apr 2015, at 22:24, Roger Riggs wrote:
> Hi Pavel,
>
> On 4/23/2015 5:12 PM, Pavel Rappo wrote:
>> Hey Roger,
>>
>> 1. Good catch! This thing also applies to java.io.InputStream.read(byte[],
>> int, int):
Yes, good catch indeed.
>> * In every case, elements b[0] through
>> *
On 23/04/2015 21:22, Remi Forax wrote:
On 04/23/2015 04:41 PM, Alan Bateman wrote:
On 23/04/2015 13:22, Remi Forax wrote:
I think the name readBytes is not very informative and the name is
too close to read + an array of bytes,
we can not use readFully (from DataInput/DataInputStream) becaus
Hi Pavel,
On 4/23/2015 5:12 PM, Pavel Rappo wrote:
Hey Roger,
1. Good catch! This thing also applies to java.io.InputStream.read(byte[], int,
int):
* In every case, elements b[0] through
* b[off] and elements b[off+len] through
* b[b.length-1] are unaffected.
I suppose the
Hey Roger,
1. Good catch! This thing also applies to java.io.InputStream.read(byte[], int,
int):
* In every case, elements b[0] through
* b[off] and elements b[off+len] through
* b[b.length-1] are unaffected.
I suppose the javadoc for the method proposed by Chris has started its
Hi Chris,
A minor inconsistency about the unmodified contents of b[off].
* The first byte read is stored into element {@code b[off]}
vs.
* In every case, elements {@code b[0]} through {@code b[off *-
1*]} and
* elements__{@code b[off+len]} through {@code b[b.length-1]} are
unaffected.
On 04/23/2015 04:41 PM, Alan Bateman wrote:
On 23/04/2015 13:22, Remi Forax wrote:
I think the name readBytes is not very informative and the name is
too close to read + an array of bytes,
we can not use readFully (from DataInput/DataInputStream) because
instead of returning the number of byte
On 04/23/2015 06:21 PM, Chris Hegarty wrote:
On 23 Apr 2015, at 16:58, Bernd Eckenfels wrote:
Hello,
I would use the already established name readFully(byte[]) and
readFully(byte[],int,int) to be consistent with DataInputStream.
I purposefully stayed away from the name ‘readFully' as the s
On 04/23/2015 06:21 PM, Chris Hegarty wrote:
On 23 Apr 2015, at 16:58, Bernd Eckenfels wrote:
Hello,
I would use the already established name readFully(byte[]) and
readFully(byte[],int,int) to be consistent with DataInputStream.
I purposefully stayed away from the name ‘readFully' as the
On 23 Apr 2015, at 16:58, Bernd Eckenfels wrote:
> Hello,
>
> I would use the already established name readFully(byte[]) and
> readFully(byte[],int,int) to be consistent with DataInputStream.
I purposefully stayed away from the name ‘readFully' as the spec for
DataInputStream.readFully and th
On 23 Apr 2015, at 17:10, Peter Levart wrote:
> On 04/23/2015 04:50 PM, Chris Hegarty wrote:
>> Peter,
>>
>> Ah, good point. Do we really need a new Exception type for this, is this
>> information really that useful? How can you recover?
>>
>> What if this error condition was better cover in t
On 04/23/2015 04:50 PM, Chris Hegarty wrote:
Peter,
Ah, good point. Do we really need a new Exception type for this, is this
information really that useful? How can you recover?
What if this error condition was better cover in the API.
* If an I/O error occurs reading from the input stream
Right you are, David. So this exception could be reused albeit the cause
of "interruption" can be arbitrary IOException thrown in the midst of
two read() calls. But the caller need not care as the outcome is the same.
Regards, Peter
On 04/23/2015 04:30 PM, David M. Lloyd wrote:
I believe this
Hello,
I would use the already established name readFully(byte[]) and
readFully(byte[],int,int) to be consistent with DataInputStream.
Gruss
Bernd
Peter,
Ah, good point. Do we really need a new Exception type for this, is this
information really that useful? How can you recover?
What if this error condition was better cover in the API.
* If an I/O error occurs reading from the input stream, then it may do
* so after some, but not all, by
On 23/04/2015 13:22, Remi Forax wrote:
I think the name readBytes is not very informative and the name is too
close to read + an array of bytes,
we can not use readFully (from DataInput/DataInputStream) because
instead of returning the number of bytes read, it throws a
EOFException if the end o
I believe this is similar to how InterruptedIOException works, FWIW.
On 04/23/2015 09:20 AM, Peter Levart wrote:
Hi Chris,
Currently InputStream guarantees that either some bytes are read *xor*
EOF (-1) is returned *xor* IOException is thrown. Even with default
implementation of read(byte[], in
Hi Chris,
Currently InputStream guarantees that either some bytes are read *xor*
EOF (-1) is returned *xor* IOException is thrown. Even with default
implementation of read(byte[], int, int) which is implemented in terms
of int read(). This new method can throw IOException after some bytes
hav
I think the name readBytes is not very informative and the name is too
close to read + an array of bytes,
we can not use readFully (from DataInput/DataInputStream) because
instead of returning the number of bytes read, it throws a EOFException
if the end of the stream is reached.
so what about
Hi Chris,
The spec looks good. The only single detail I've noticed is that the "an
exception is thrown" as a possible cause of unblocking the method is missing:
--- dev/jdk/src/java.base/share/classes/java/io/InputStream.java (revision )
+++ dev/jdk/src/java.base/share/classes/java/io/InputStre
A while back when we added the long overdue java.io.InputStream.transferTo
method, there was support for adding a blocking bulk read operation. This has
been sitting in a branch in the sandbox since then. I would like to revive it
with the intention of bringing it into 9. The motivation for this
32 matches
Mail list logo
