RFR: 8346573: Can't use custom default file system provider with custom system class loader

[Maxim Kartashev]

On Fri, 20 Dec 2024 09:47:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If an application is deployed to use a custom default file system provider, and a custom system class loader, and initialisation of the custom system class loader uses the file system APIs, then it leads to a recursive initialisation issue. This issue has always existed but has only recently been reported. Using both configuration knobs at the same time is probably very rare but it does require attention in advance of any proposals that re-implement the java.io file classes on java.nio.file.
> 
> The proposed change here is to re-specify FileSystems.getDefault to use the default system class loader when locating the custom default file system provider. In spec terms, this is changing "system class loader" to "default system class loader" with a link to its meaning in ClassLoader.getSystemClassLoader. As part of the change I've expanded the wording to specify that the custom default file system provider must be public in a package exported to at least java.base, and that the one-arg constructor also be public. This additional clarification specifies long standing behavior and does not change any implementation.
> 
> The SetDefaultProvider.java test is expanded to add a new test the runs with both a custom default file system provider and custom system class loader, and where where the custom system class loader uses the file APIs in its initialisation.

I'm not a reviewer, but this does solve the problem with the circular initialization that we had.

test/jdk/java/nio/file/spi/CustomSystemClassLoader.java line 38:

> 36:         // use default file system
> 37:         FileSystem fs = FileSystems.getDefault();
> 38:         var path = fs.getPath("foo");

Maybe print the path out so that the whole thing does not get optimized away as vacuous in accordance with the language rules?

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

Marked as reviewed by mkartashev (no project role).

PR Review: https://git.openjdk.org/jdk/pull/22842#pullrequestreview-2517640245
PR Review Comment: https://git.openjdk.org/jdk/pull/22842#discussion_r1893988101