RFR: 8265891: ChannelInputStream.transferTo() uses FileChannel.transferTo()

[Markus KARG]

On Thu, 19 Aug 2021 13:10:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I had hoped that ThrowingLongSupplier would go away. If you keep your 2-arg transfer method then we should be able to implementation transferTo very simply, something like
> 
> ```
>         public long transferTo(OutputStream out) throws IOException {
>             if (ch instanceof FileChannel fc
>                     && out instanceof ChannelOutputStream cos) {
>                 WritableByteChannel target = cos.channel();
>                 if (target instanceof SelectableChannel sc) {
>                     synchronized (sc.blockingLock()) {
>                         if (!sc.isBlocking())
>                             throw new IllegalBlockingModeException();
>                         return transfer(fc, target);
>                     }
>                 }
>                 return transfer(fc, target);
>             }
>             return super.transferTo(out);
>         }
> ```

This is not true. It will only check the blocking mode for the target. But technically it is possible that someone writes an implementation of FileChannel which implements SelectableChannel. In that case it is needed to check the blocking mode on the source, too. So either we (a) ignore this possibility, (b) write a very complex code which calls transfer(fc, target) in FOUR code paths not just two, or (c) we keep the ThrowingLongSupplier as an elegant way to perform the 2x2 matrix.

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

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