Set context class loader to the system one when loading the default filesystem providers

[aloubyansky]

Fixes #9017
Fixes #7424

These two issues were reported by the same user. They are different but both reproducers are affected by #9017

[stuartwdouglas]

This does not seem right. FileSystemProvider is part of the JDK, there should never be multiple implementations of it (in fact you can't have multiple impls, because the JDK will stop you).

[aloubyansky]

How about https://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/filesystemprovider.html ?

[aloubyansky]

Have you checked the original issue?

[stuartwdouglas]

Caused by: java.lang.ClassCastException: Cannot cast org.apache.sshd.common.util.security.bouncycastle.BouncyCastleSecurityProviderRegistrar to org.apache.sshd.common.util.security.SecurityProviderRegistrar at java.base/java.lang.Class.cast(Class.java:3605)

This must be because the FS lookup is not using the TCCL, but some other provider is.

Is there any reason why we don't pass the TCCL to the ServiceLoader here?

[aloubyansky]

It is using the TCCL but the JDK is using the system classloader to load the "installed" providers. The test deps are visible to the system classloader so this is where it picks it up.

[aloubyansky]

Well, the JDK actually allows you to provide your own classloader which we don't in this specific case. But even if we did it wouldn't affect this use-case. Because it always loads the providers from the system classloader first and then from the user provided cl.

[aloubyansky]

Looks at java.nio.file.spi.FileSystemProvider.loadInstalledProviders()

[stuartwdouglas]

Looks like there is not much else that can be done here.

The global provider list is being loaded from the system CL, but then if the TCCL is set the sshd provider attempts to use the TCCL to load some classes.