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

Alan Bateman alanb at openjdk.org
Sat Dec 21 08:10:38 UTC 2024


On Sat, 21 Dec 2024 02:34:17 GMT, ExE Boss <duke 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.
>
> src/java.base/share/classes/java/nio/file/FileSystems.java line 116:
> 
>> 114:                 for (String cn: propValue.split(",")) {
>> 115:                     try {
>> 116:                         Class<?> c = Class.forName(cn, true, ClassLoaders.appClassLoader());
> 
> Note that this might break the case where a custom system `ClassLoader` doesn’t depend on a custom default `FileSystemProvider` but the latter depends on the custom system `ClassLoader`, so this should call `ClassLoaders​::appClassLoader()` only when `VM.isBooted()` is `false`.

A custom default file system provider can't depend on a custom system ClassLoader. Think of access to the default file system as something that works at a much lower level that a class loader.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22842#discussion_r1894582246


More information about the nio-dev mailing list