New release DefaultFileSystemProviders

[Michael Hall]

> On Jul 29, 2021, at 2:52 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 29/07/2021 01:46, Michael Hall wrote:
>> 
>> 
>> If of interest, change that test to mine.
>> 
>> /usr/libexec/java_home --exec java -cp .:macnio2 -Djava.security.manager -Djava.security.policy=all.policy -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider --module-path mods --add-modules us.hall.trz.osx,org.openjdk.nashorn,java.compiler,java.desktop,java.logging,java.management,java.prefs,java.se <http://java.se/>,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell,jdk.crypto.ec,jdk.jdeps,jdk.jcmd  --add-exports org.openjdk.nashorn/org.openjdk.nashorn.tools=ALL-UNNAMED org.test.Test 
>> Error occurred during initialization of VM
>> java.lang.Error: java.lang.NullPointerException: Cannot invoke "java.nio.file.FileSystem.getPath(String, String[])" because the return value of "java.nio.file.FileSystems.getDefault()" is null
> 
> Thanks for the stack trace, I think I understand it. It's another bootstrapping issue that arises when starting with a security manager, replacing the default file system provider, and running with an application module path. So three planets need to align to create the conditions. So while the changes in JDK-8266345 are correct, it's not the complete fix and there is work beyond the PolicyFile change to be able to startup with this configuration. I'll create another bug to track this and we'll try again.
> 
> -Alan

I hadn’t thought to change to the prior test before to get a stack crawl. I was getting pretty sure Astrology was involved somehow. If I can get a trace for the non-modular launch I’ll post that too. I’m pretty sure it is different.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210729/c9f80b5a/attachment-0001.htm>