RFR: 8358688: HttpClient: Simplify file streaming in RequestPublishers.FilePublisher [v2]

[Daniel Fuchs]

On Fri, 6 Jun 2025 08:11:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add back removed SM tests

The new version LGTM. I wonder if we should add `@bug 8358688` to the various FilePublisher test - or just consider the fix as noreg-cleanup. On the one hand those tests might have failed if you hadn't catched and transformed NSFE. On the other hand they should pass whether this fix is present or not...

src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:

> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");

I wonder if we should keep `nsfe` as the cause. Does it contain anything interesting in the stack trace that could help debugging if it gets unexpectedly thrown?

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

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2948485426
PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2131758853