Circular loading of installed providers detected

[Michael Hall]

> On Sep 30, 2021, at 4:25 AM, Michael Hall <mik3hall at gmail.com> wrote:
>> 
> 
> Possibly the code could at some point check the java.nio.file.spi.DefaultFileSystemProvider property to be sure it wasn’t trying to reload the current default anyhow.

It still seems a bit of a awkward workaround but for a DefaultFileSystemProvider that saves its priorProvider static and includes a no-args that does nothing it works. I’m not sure if this would be necessary for any code that uses multiple providers. Or just code that replaces the default and then tries for another provider.

For this 

error: No file system provider is available to handle this file: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app/halfpipe.j
I found this indicating I needed an additional module…

https://www.mail-archive.com/jigsaw-dev@openjdk.java.net/msg07033.html <https://www.mail-archive.com/jigsaw-dev@openjdk.java.net/msg07033.html>

A comment might be that neither suggested error message tells you anything about needing a module.

Adding that module exposed a bug in my provider getFileAttributeView method that when fixed got me…

System.out.println("Hello, World!")
Hello, World!

So not that ugly a workaround anymore.

A comment there still might be that loading recursion could be avoided. 
Having

static boolean loaded = false;

MyProvider() {
	loaded = true;
}

public static boolean isLoaded() { return loaded; }

If my workaround needs a static priorProvider it seems like this wouldn’t be any worse and could eliminate recursion? 
Also definitely checking the DefaultFileSystemProvider so you don’t try to reload that seems like it makes sense?

Thanks for the replies.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210930/f02888bc/attachment.htm>