As a reference point: int java.io.InputStream.read(byte[] b) throws IOException
Reads some number of bytes from the input stream and stores them into the buffer array b. The number of bytes actually read is returned as an integer. This method blocks until input data is available, end of file is detected, or an exception is thrown. If the length of b is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at the end of the file, the value -1 is returned; otherwise, at least one byte is read and stored into b. The first byte read is stored into element b[0], the next one into b[1], and so on. The number of bytes read is, at most, equal to the length of b. Let *k* be the number of bytes actually read; these bytes will be stored in elements b[0] through b[*k*-1], leaving elements b[*k*] through b[b.length-1] unaffected. The read(b) method for class InputStream has the same effect as: read(b, 0, b.length) Parameters:*b* the buffer into which the data is read.Returns: the total number of bytes read into the buffer, or -1 if there is no more data because the end of the stream has been reached.Throws:IOException - If the first byte cannot be read for any reason other than the end of the file, if the input stream has been closed, or if some other I/O error occurs. NullPointerException - if b is null.See Also:java.io.InputStream.read(byte [], int, int) On Mon, Sep 2, 2019 at 11:57 AM Stefan Bodewig <bode...@apache.org> wrote: > Hi all > > https://issues.apache.org/jira/browse/COMPRESS-491 correctly points out > that some of our InputStream implementantions violate the contract of > the read(byte[]...) pair of methods. They may return 0 instead of trying > to block and read data. > > Digging deeper this really only seems to happen on purpose in > Deflate64CompressorInputStream and I've fixed that. > > Many of our other stream implementations wrap other streams and may > return 0 if the underlying stream does. I don't think we should be > stricter than the stream we wrap here. Do you think we should? > > A special case is where we use SeekableByteChannel in ZipFile and > SevenZFile. The read method of ReadableByteChannel is allowed to return > 0 on read for non-blocking channels. I think seekable channels are > extremely unlikely to be non-blocking, so I'd stick with documenting the > fact. The alternative would be a busy loop (or retry with sleeps and > exponential backoff or something similar). > > Thoughts? > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
