RFR: 8298658: Platform-specific type leaks to platform independent code.

[Alfonso² Peterssen]

On Wed, 14 Dec 2022 13:37:32 GMT, Alfonso² Peterssen <duke at openjdk.org> wrote:

> This is not a cosmetic change, it enforces the isolation of platform-specific code from the user-facing API.
> 
> `sun.nio.fs.DefaultFileSystemProvider#instance()` has a platform-specific return type. This makes the platform-independent `java.nio.file.FileSystems.DefaultFileSystemHolder#getDefaultProvider()` have a platform-dependent call e.g. INVOKESTATIC with different signatures.
> 
> The platform-specific return types were introduced in [JDK-8213406](https://bugs.openjdk.org/browse/JDK-8213406), the common SPI type was used before. There's no reason to leak types to platform-independent code, except for tests, which could just cast.
> 
> This change is motivated by [Espresso](https://github.com/oracle/graal/tree/master/espresso), a meta-circular, spec-compliant JVM written in Java. Espresso aims to provide a custom Java IO/NIO implementation on top of any vanilla JDK as a viable alternative to the imminent removal of `SecurityManager`.

NIO has a very clean separation between platform-dependent FS implementations and user-facing APIs, this is the only pain point we found.

Our goal (in Espresso) is to override the platform-dependent FS, not just the apllication FS.

### The issue

On different OSs, the method [java.nio.file.FileSystems.DefaultFileSystemHolder#getDefaultProvider()](https://github.com/openjdk/jdk/blob/ebb84ad70d3295d9a429904fcdacdb8ecd1bf434/src/java.base/share/classes/java/nio/file/FileSystems.java#L112-L140) is compiled differently by javac.

The difference is on the signature of the call to [sun.nio.fs.DefaultFileSystemProvider#instance()](https://github.com/openjdk/jdk/blob/ebb84ad70d3295d9a429904fcdacdb8ecd1bf434/src/java.base/share/classes/java/nio/file/FileSystems.java#L114) which returns a hard-coded {Linux|Windows|Aix|MacOSX}FileSystemProvider depending on the OS it was compiled on.

We'd like to replace the platform FS with a custom one e.g. read-only FS, a FS with restricted access to some specific folder/files..., in-memory FS, or in the context of native-image, a FS that only has access to the resources embedded within the native executable...
Overriding the platform FS is more difficult that it should be because of this leak. Changing the [signature](https://github.com/openjdk/jdk/blob/ebb84ad70d3295d9a429904fcdacdb8ecd1bf434/src/java.base/linux/classes/sun/nio/fs/DefaultFileSystemProvider.java#L43) to return a `FileSystemProvider` on all OSs fixes the leak without any down-sides.

On a final note, the proposed change is trivial and is not meant to enable some dark feature alien to OpenJDK. The change enforces a clean separation between NIO platform-independent code and platform-dependent FS implementations.

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

PR: https://git.openjdk.org/jdk/pull/11674