Circular loading of installed providers detected
Michael Hall
mik3hall at gmail.com
Tue Oct 5 17:30:44 UTC 2021
> On Oct 5, 2021, at 9:01 AM, Michael Hall <mik3hall at gmail.com> wrote:
>
>
>
>> On Oct 5, 2021, at 8:58 AM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>>>
>> jdk.zipfs is a service provider module so no module requires it. So yes, you'll ned to keep it on the list of modules that you specify to the jlink --add-modules option.
>>
>> -Alan
>
> Yes, I assumed this. What seems incorrect is that although I add it at jdk16 it still didn’t get included.
>
It might of been service provider failing due to my custom default provider somehow. I couldn’t recreate with just jlink. Falling back to 16 isn’t that easy at this point. OS/X entitlements worked differently, there was a java.library.path issue at 16. I removed the parameter for DefaultFileSystemProvider but I think at some point it still was being found in discovery and it won’t work at 16. I removed the jar as well. I guess this seems the most likely cause of the missing zipfs module but I didn’t isolate it to that for sure.
The application itself still doesn’t launch double clicked, indicating incomplete, but if I double click the MacOS executable it runs. And the 3rd party code works. (Although still showing the error I thought it was failing on) I’ll probably have to fix the double click failure somehow before providing it for anyone to try.
So some confusion still between versions and mixing in my provider and maybe building the app but it does seem specific to what mine is doing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20211005/6e1cfca9/attachment-0001.htm>
More information about the nio-dev
mailing list