Changing the default file system provider is broken :(

[Alan Bateman]

On 23/04/2017 19:28, Remi Forax wrote:

> :
> This should be added to the compatibility list because mocking the FileSystem for testing purpose is common, at least in my own bubble.
>
I would prefer not introduce compatibility issues in this area if 
possible. I think the best we can do is read the 
java.nio.file.spi.DefaultFileSystemProvider property on first usage 
after the module system is initialized.

So assume you set the property in your main method:

1. If an agent is started before your main, and the agent uses the file 
system API in its initialization, then the built-in provider will be 
used. This is the same as JDK 7 and JDK 8.

2. If a custom system class loader or a custom security manager is 
configuration, and if the initialization of either uses the file system 
API, then the built-in provider will be used. This is the same as JDK 7 
and JDK 8.

If set on the command line:

(a) If an agent uses the file system API then it will use the custom 
provider. This is the same as JDK 7 and JDK 8.

(b) If a custom system class loader or a custom security manager 
attempts to use the file system API then it will fail with a recursive 
initialization error or exception (it varies). This is because the 
custom file system provider is located using the system class loader. 
This is the same as JDK 7 and JDK 8 although the exception/error is 
different as this area has been cleared up a lot in JDK 9.

We could improve (b) by changing the spec to allow custom file system 
providers be located before the system class loader is initialized but 
it hardly seems worth it.

Do you agree with this? If so then we can get the implementation aligned 
and create some issues in JIRA to ensure that we have tests to cover all 
these scenarios.

-Alan