<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="auto">Hi everyone,<div dir="auto"><br></div><div dir="auto">I'm new to this mailing list and have been working on a library to make tar files with zero copy and in the past worked on zero-copy optimizations in the AWS SDK. I've run into the FileChannel-only restriction for transfer methods and wanted to understand whether generalizing these APIs has been considered or if there are fundamental blockers I'm not aware of.</div><div dir="auto"><br></div><div dir="auto">## Context: My Experience with the Current Limitation</div><div dir="auto"><br></div><div dir="auto">While working on zero-copy improvements for AWS SDK Java v2 ([#3928](https://github.com/aws/aws-sdk-java-v2/issues/3928), [PR #3925](https://github.com/aws/aws-sdk-java-v2/pull/3925), [PR #4096](https://github.com/aws/aws-sdk-java-v2/pull/4096)), I encountered the issue where they used Flow.Publisher<ByteBuffer> to make a consistent API for http client implementations however the downside of this is that the netty transport layer can't make use of its FileRegion abstraction for zero copy.</div><div dir="auto"><br></div><div dir="auto">For example, in the tar file creation scenario I'm working on:</div><div dir="auto">```java</div><div dir="auto">// What I'll end up writing:</div><div dir="auto">if (source instanceof FileChannel fc) {</div><div dir="auto">    fc.transferTo(destination...);</div><div dir="auto">} else {</div><div dir="auto">    // Manual buffer copying for everything else</div><div dir="auto">    ByteBuffer buffer = ByteBuffer.allocateDirect(8192);</div><div dir="auto">    while (source.read(buffer) != -1) {</div><div dir="auto">        buffer.flip();</div><div dir="auto">        destination.write(buffer);</div><div dir="auto">        buffer.clear();</div><div dir="auto">    }</div><div dir="auto">}</div><div dir="auto">```</div><div dir="auto"><br></div><div dir="auto">## A Possibly Naive Question</div><div dir="auto"><br></div><div dir="auto">I'm wondering if it might make sense to add default transferTo/transferFrom methods to the base channel interfaces? I realize there might be good reasons this hasn't been done, but I'm curious about the tradeoffs.</div><div dir="auto"><br></div><div dir="auto">```java</div><div dir="auto">// What would be nice:</div><div dir="auto">source.transferTo(destination, 0, size);  // Works for any ReadableByteChannel</div><div dir="auto">// Or</div><div dir="auto">destination.transferFrom(source, 0, size) // Works for any WritableByteChannel</div><div dir="auto">```</div><div dir="auto"><br></div><div dir="auto">Under the hood I would then expect Java to choose the most efficient option e.g if FileChannel is on the left or right where `sendfile()` can be used it should choose that route.</div><div dir="auto">Slight tangent but I also wonder if bytebuffer should implement these interfaces.</div><div dir="auto"><br></div><div dir="auto">## Potential Benefits I'm Seeing</div><div dir="auto"><br></div><div dir="auto">From my limited perspective, this could:</div><div dir="auto"><br></div><div dir="auto">1. **Simplify application code** - One code path instead of checking channel types</div><div dir="auto">2. **Allow future optimizations** - As new OS capabilities emerge (io_uring, Project Panama improvements), the JVM could optimize under the hood without API changes</div><div dir="auto">3. **Let frameworks contribute optimizations** - Netty and others have sophisticated zero-copy implementations that could be exposed through standard APIs</div><div dir="auto"><br></div><div dir="auto">## Questions I Have</div><div dir="auto"><br></div><div dir="auto">I'm genuinely curious about the history and constraints here:</div><div dir="auto"><br></div><div dir="auto">- Has this been proposed before and rejected? If so, what were the blocking concerns?</div><div dir="auto">- Are issues with channel implementations I'm not aware of that make this unworkable?</div><div dir="auto">- Would default methods in interfaces cause compatibility problems I'm not seeing?</div><div dir="auto">- Is the current restriction based on "only expose what can be optimized today" philosophy, and would that make this inappropriate?</div><div dir="auto"><br></div><div dir="auto">I understand that mainly FileChannel has OS-level zero-copy support and that's why it's been implemented, but I'm wondering if having a consistent API might still be valuable even if some combinations just fall back to buffer copying (which we're doing manually anyway).</div><div dir="auto"><br></div><div dir="auto">## Not Looking for Perfection</div><div dir="auto"><br></div><div dir="auto">I'm fully expecting this to be intentional but would love to understand:</div><div dir="auto">- Why the current design is the way it is</div><div dir="auto">- Whether there's any interest in exploring this direction</div><div dir="auto">- What challenges I'm not seeing from my application-developer perspective</div><div dir="auto">- An insight into the process for this sort of thing</div><div dir="auto"><br></div><div dir="auto">I'd really appreciate any historical context, technical insights, or general thoughts on whether this is worth pursuing or if I should just accept the current design as a deliberate and permanent choice.</div><div dir="auto"><br></div><div dir="auto">Thanks for taking the time to read this, and I apologize if this has been discussed to death already - I couldn't find previous discussions in my searching.</div><div dir="auto"><br></div><div dir="auto">Best regards</div></div>