RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13]

[Markus KARG]

On Thu, 12 Aug 2021 08:40:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Draft: Eliminated duplicate code using lambda expressions
>>  - Draft: Use blocking mode also for target channel
>
>> I am a bit disappointed actually about that destructive answer at that late point in time, now that I worked for months on all the requested changes and tests. To prevent exactly this situation, I deliberately had the discussion started in JIRA only, and I deliberately had the original code being just a draft in the first place, and I deliberately did nearly _everything_ I was asked to (including even the most irrelevant minor code style issues). And you come up with the request to drop the code **now**?
>> 
>> Certainly we could reduce the PR to just file channels, but in fact, now that I spent all the time in the non-file-channels, I wonder why I shall throw away all that work and go just with file channels actually? What is not covered that was originally covered, and what is that lots of issues you talk about? Actually I cannot see the actual problem unless you name it.
> 
> There are 78 comments on this PR so far. We've tried to point out the bugs and issues at each iteration. We asked for tests because the changes introduce several code paths and implementations that would not be exercised by existing tests. There are several scenarios still missing and the patch doesn't yet have the microbenchmarks to demonstrate the improvements.
> 
> I assume this is your first contribution so there will be learning curve and maybe some frustration. I think you have a better chance of success if you split this up and reduce the scope of this PR down to something manageable. Keeping the selectable channels out of this PR and focusing on the case where the input and output streams wrap file channels should make it simpler and may lead to a better solution. Reducing the scope will also reduce the burden on reviewers.

> I do not know exactly what @AlanBateman had in mind, but I think there is general concern about ensuring that all combinations of channel types and all execution paths are exercised.

@AlanBateman @bplb 

Does it make **any** real sense to answer your recent questions, provide the proofs, tests and benchmark results (I actually would love to *if* it makes sense) *or* will the outcome be that I *must* drop everything besides file channels *anyways* (In that case it is in vain)? As my time is just as precious as yours I really need to know that **before** I spend more weeks into code paths that you possibly decided to never accept ever. Don't get me wrong, if you see a chance to keep the code once I provided the answers I will do that, but if you do not see that chance, please frankly and unambiguously tell me **now**. Thanks.

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

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