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
