Circular loading of installed providers detected

[Alan Bateman]

On 29/09/2021 23:18, Michael Hall wrote:
> I eliminated the no args constructor and added a couple printStackTrace’s of my own in the constructors. I get this at startup
>
> java.lang.Exception: MacFileSystemProvider(fsp)
> 	at us.hall.trz.osx.MacFileSystemProvider.<init>(MacFileSystemProvider.java:57)
> 	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
> 	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
> 	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Unknown Source)
> 	at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source)
> 	at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(Unknown Source)
>
> This invoking jshell from the app after getting rid of the no args constructor…
>
> Caused by: java.util.ServiceConfigurationError: java.nio.file.spi.FileSystemProvider: us.hall.trz.osx.MacFileSystemProvider Unable to get public no-arg constructor
> 	at java.base/java.util.ServiceLoader.fail(Unknown Source)
> 	at java.base/java.util.ServiceLoader.getConstructor(Unknown Source)
> 	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(Unknown Source)
> 	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Unknown Source)
> 	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator$1.run(Unknown Source)
> 	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
> 	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Unknown Source)
> 	at java.base/java.util.ServiceLoader$2.hasNext(Unknown Source)
> 	at java.base/java.util.ServiceLoader$3.hasNext(Unknown Source)
> 	at java.base/java.nio.file.spi.FileSystemProvider.loadInstalledProviders(Unknown Source)
> 	at java.base/java.nio.file.spi.FileSystemProvider$1.run(Unknown Source)
> 	at java.base/java.nio.file.spi.FileSystemProvider$1.run(Unknown Source)
> 	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
> 	at java.base/java.nio.file.spi.FileSystemProvider.installedProviders(Unknown Source)
> 	at jdk.compiler/com.sun.tools.javac.file.FSInfo.getJarFSProvider(Unknown Source)
>
> So eliminating the no args is not a fix. Apparently mixing in a JarFSProvider has a conflict?
> I don’t think my code can handle this itself as it fails with or without the no args.
I should have been clearer. I meant that if you have a 1-arg constructor 
then you should be able to remove your code that iterates over the 
installed provider to find the built-in/default provider.

Also just to say that the spec has always had a warning about recursive 
initialization:

"During construction a provider may safely access files associated with 
the default provider but care needs to be taken to avoid circular 
loading of other installed providers. If circular loading of installed 
providers is detected then an unspecified error is thrown."

-Alan.