New release DefaultFileSystemProviders

[Alan Bateman]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210729/75896a72/attachment.htm>