New release DefaultFileSystemProviders

[Michael Hall]

> On Jul 30, 2021, at 7:47 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jul 30, 2021, at 7:42 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> 
>> 
>> 
>>> On Jul 30, 2021, at 7:40 PM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>> 
>>> 
>>>> On Jul 30, 2021, at 5:21 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>>>> 
>>>>>> Yes, the exploded case should be okay. However, if java.nio.file.spi.DefaultFileSystemProvider specifies a class in a JAR file that is on the class path or module path then you'll run into this issue.  Setting the security manager on the command line will trigger this occur at VM startup.
>>>>>> -Alan
>>>>> 
>>>>> Thanks for explaining the conditions. I will hold off on additional testing for now.
>>>>> 
>>>> If you could maybe post the bug report number so I can track when I might test again. 
>>>> 
>>>> Thanks again.
>>> 
>>> This is it, I think: https://bugs.openjdk.java.net/browse/JDK-8263940 <https://bugs.openjdk.java.net/browse/JDK-8263940>
>>> 
>>> Brian
>> 
>> Looks correct. Thanks Brian.
>> 
> Actually the stack trace looks somewhat different from what I previously posted but I assume duplicates the same issue.

Yeah, should of noticed, that was the first bug report with a jar class path that could be worked around by including the provider in an exploded directory. That works at jdk12. There is no current workaround.
Could still use a number so I can include the provider with a current version of the application when it is fixed.

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