On Thu, 12 Aug 2021 08:40:34 GMT, Alan Bateman <al...@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
