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

[Alan Bateman]

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.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/22842/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22842&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346573
  Stats: 72 lines in 3 files changed: 58 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/22842.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22842/head:pull/22842

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