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

[Jaikiran Pai]

On Fri, 6 Jun 2025 11:49:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> The "default file system" is required to support that feature, but there can be other file systems that support that too.
>> 
>> I need to amend this statement: Per [`Path::toFile` specification]( https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toFile()), except the default one obtained by `FileSystems::getDefault`, `FileSystem` implementations are expected to throw `UnsupportedOperationException` on `Path::toFile`. Note that this is enforced by the specification; there is technically nothing blocking a custom `FileSystem` implementation from returning a `File` (i.e., not throwing `UOE`) from `Path::toFile`.
>
> Thanks for the clarification.

Hello Volkan,

> Earlier the regular file check was performed by FIS::new at subscription, hence, NSFE (yes, FIS::new throws NSFE when passed a not-regular file, e.g., a directory) was thrown at subscribe()

The `NoSuchFileException` is a NIO construct and resides in `java.nio.file` package. So the older `java.io.FileInputStream`'s constructor throwing a `NoSuchFileException` felt odd to me. So I tried this:


jshell> new FileInputStream(new File("/tmp"))


that throws a `FileNotFoundException` (which is understandable) and not a `NoSuchFileException`


|  Exception java.io.FileNotFoundException: /tmp (Is a directory)
|        at FileInputStream.open0 (Native Method)
|        at FileInputStream.open (FileInputStream.java:185)
|        at FileInputStream.<init> (FileInputStream.java:139)
|        at (#1:1)


Was it something else in that test failure which was throwing the `NoSuchFileException`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2134763715