RFR: 8329829: HttpClient: Add a BodyPublishers.ofFileChannel method [v8]

[Daniel Fuchs]

On Mon, 11 Aug 2025 07:47:03 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Adds a new `ofFileChannel(FileChannel channel, long offset, long length)` method to `java.net.HttpRequest.BodyPublishers` to provide an `HttpClient` publisher to upload a certain region of a file. The new publisher does not modify the state of the passed `FileChannel`, streams the file channel bytes as it publishes (i.e., avoids reading the entire file into the memory), and can be leveraged to implement sliced uploads. As noted in the Javadoc:
>> 
>>> The file channel will not be closed upon completion. The caller is
>>> expected to manage the life cycle of the channel, and close it
>>> appropriately when not needed anymore.
>> 
>> ### Implementation notes
>> 
>> - `FileChannel` is preferred over `{Readable,Seekable}ByteChannel`, since the latter does not provide a positional read without modifying the state of the `FileChannel`, which is necessary to use a single `FileChannel` instance to implement sliced uploads.
>> - `ofFileChannel(FileChannel,long,long)` is preferred over `ofPath(Path,long,long)` to avoid overloading the maximum file descriptor limit of the platform.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve style for declaring multiple consecutive fields of the same type

I'm not sure saying "this method doesn't change the channel position" is appropriate - indeed it's not the method that would potentially change the channel position but the body publisher it returns.

On the one hand, not mentioning explicitely that we use `FileChannel#read(ByteBuffer, long)` doesn't lock us on the implementation; on the other hand it leaves some uncertainty on how we achieve this and whether concurrency would effectively work (we could be locking the channel and resetting its position for instance).

I like the idea of moving that information into an `@apiNote`. Maybe a cross between your suggested change and what Volkan currently has? Also - though uploading non-overlapping portions of the file is how you would usually use the publisher, it is not required that the portions are non-overlapping for concurrency to work correctly.

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

PR Comment: https://git.openjdk.org/jdk/pull/26155#issuecomment-3199960642