On Mon, 16 Jun 2025 14:07:57 GMT, p-nima <d...@openjdk.org> wrote: > as the path would be dependent on the provider
Correct, a `Path` implementation depends on the `FileSystem` implementation. Except _"the default file system"_, obtained by invoking [`FileSystems::getDefault`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/FileSystems.html#getDefault()), `Path::toFile` method of the associated `Path` implementation is _expected_ to throw `UnsupportedOperationException` – see [the `Path::toFile` specification for details](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toFile()). > it is essential to test a custom provider (in this case SecureZipFSProvider) `HttpRequest.BodyPublishers#ofFile(Path)` was not working when the `Path` provided is associated with a file system that does not support `Path::toFile`, i.e., throwing `UnsupportedOperationException` on `Path::toFile`. [JDK-8235459](https://bugs.openjdk.org/browse/JDK-8235459) addresses this issue. The fix also contains tests covering all following file systems: 1. The default file system (`Path::toFile` actually works, but gets tested to verify) 2. `ZipFileSystem` (`Path::toFile` is not supported) 3. `SecureZipFS` (a `ZipFileSystem` wrapper regulating access via `SecurityManager`) `SecurityManager` was removed in [JDK-8344228](https://bugs.openjdk.org/browse/JDK-8344228), yet `SecureZipFS` was stripped from `SecurityManager`-related calls. In this PR, we're doing what should have been done instead: deleting it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25747#issuecomment-2977585177