RFR: 8359223: HttpClient: Remove leftovers from the SecurityManager cleanup [v2]

[Volkan Yazici]

On Mon, 16 Jun 2025 14:07:57 GMT, p-nima <duke at 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