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
