On Fri, 6 Jun 2025 08:21:31 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>>> I believe the old code was not always throwing `FileNotFoundException` - >>> but might have thrown `NoSuchFileException` if using a non-default >>> filesystem. >> >> @dfuch, correct. If `Path` is associated with a file system that doesn't >> support `Path::toFile`<sup>1</sup>, earlier users would get `Files::newIS` >> exceptions (which were indeed undocumented), whereas others would get >> `FIS::new` exceptions. >> >> <sup>1</sup> Allow me to note that I intentionally avoid using "default file >> system" term, since, IMHO, that distracts us from the problem: file systems >> that don't support `Path::toFile`. The "default file system" is required to >> support that feature, but there can be other file systems that support that >> too. > > OK > 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`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2132007324
