Circular loading of installed providers detected

Michael Hall mik3hall at gmail.com
Wed Sep 29 22:18:15 UTC 2021


>>> 
>> If you change the public constructor to have a FileSystemProvider parameter then it will be called with a reference to the built-in provider. That should avoid the need to iterated through the installed providers.
>> 

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.



More information about the nio-dev mailing list