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

Reply via email to