答复: 答复: 答复: (fc) FileChannel.transferFrom/transferFromArbitraryChannel to return -1 at some error condition

[lihuaming (A)]

Got it, thanks Alan.
I will put something into apiNote of transferFrom/transferTo, it’s tracked by https://bugs.openjdk.java.net/browse/JDK-8260694.

Thanks,
Hamlin

发件人: Alan Bateman [mailto:Alan.Bateman at oracle.com]
发送时间: 2021年1月30日 16:52
收件人: lihuaming (A) <lihuaming3 at huawei.com>; nio-dev at openjdk.java.net
主题: Re: 答复: 答复: (fc) FileChannel.transferFrom/transferFromArbitraryChannel to return -1 at some error condition

On 30/01/2021 07:52, lihuaming (A) wrote:


### if the arbitrary channel was just closed by peer side, transferFrom will return 0 this time or next time, and there is no way for it knows that the underlying socket was closed, unless it calls channel.read. But for performance consideration, I think some framework/program would like to call FileChannel,transferFrom(channel, …) only, rather than followed by a read+write just in case of channel is closed by peer side; read+write can be optimized by only do it if transferFrom(channel, …) returns 0, but it still has some extra cost, and code is not simple and straight.
### I don’t think this is jdk bug and I do have concern about the compatibility too and explained to framework/program developers, but I can also understand their points, so want to see if there are some way to make it more friendly to framework/program developers in this situation. Hope I have made it clear ☺. If there is no other better solutions, I will let them know that it’s better to modify their code.

Thanks Alan for discussion.

Right, I think you get it. In this case the framework will need to fix their code.

While not the case here, I do have sympathy for those trying to using this API with a source channel that is configured non-blocking. As the method returns the number of bytes transferred (meaning read and then the written to the file) then it can't distinguish the EOF from the "no bytes available" case. This is probably something we should put into an @apiNote.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210201/5bd6dcf2/attachment.htm>