Circular loading of installed providers detected

[Michael Hall]

> On Sep 30, 2021, at 1:02 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Sep 30, 2021, at 4:25 AM, Michael Hall <mik3hall at gmail.com <mailto: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…
> 

Sort of oddly. 
I was going to come up with a JDK16 version of the application to get around some JDK17 encapsulation errors for some 3rd party code.
For JShell these messages come back…

/Users/mjh/HalfPipe/HalfPipe_jpkg/HalfPipe16.app/Contents/app/httpcore5-5.0.2.jar
error: No file system provider is available to handle this file:

My jpackage invocation still has a —add-modules that includes jdk.zipfs
If I do a —list-modules against the embedded runtime it doesn’t show up…

HalfPipe16.app/Contents/runtime/Contents/Home/bin/java --list-modules | grep zipfs

The OS/X installed jdk16 includes it…
/usr/libexec/java_home -v 16 --exec java --list-modules | grep zipfs              
jdk.zipfs at 16

I did remove the parameter for my DefaultFileSystemProvider as that did not work at jdk16. If it is being found by discovery it should be the  current version with the circular workaround. 

I am not sure why the jdk16 jpackage/jlink runtime misses the zipfs module? But so far other than looking messy starting JShell it doesn’t seem to cause any problems.

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