RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v7]

[Markus KARG]

On Tue, 14 Dec 2021 09:42:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I would say "yes, for the channels being part of the JRE", and have adopted your proposal in https://github.com/openjdk/jdk/pull/6711/commits/3c1d8af58e65b6aa5d373c69f7e29e1f10010dc1. The only risk I see (and hence I wrote that originally complex code) is that *in theory* anybody is technically able to implement a **custom** `ReadableByteChannel` (as it is a public interface) which does return zero *intermittently* while the end of stream is not reached. `transferFrom` in that case will also return zero. Hence the loop would terminate *(possibly long) before* EOF is reached.
>> 
>> So do we ignore this hypothetical case?
>
> The read method is specified so that "It is guaranteed, however, that if a channel is in blocking mode and there is at least one byte remaining in the buffer then this method will block until at least one byte is read". So in blocking mode it means that read returns >=1 or -1/EOF. You are correct that a blocking of implementation of RBC that returns 0 would be problematic. In the case of transferFrom then it would assume the channel it at EOF. In other usages it may cause a loop as the caller might not expect 0. A completely broken implementation might return random values (-2 !!) so I don't think we can reliably defend against all cases. So I think the updated implementation in 3c1d8af5 is okay.

Ah, right, seems I missed that section about the one-byte-guarantee. Great, so I kindly request approval of this PR!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6711