Replacing default FileSystemProvider
Bernd Eckenfels
ecki at zusammenkunft.net
Sat Mar 20 22:24:20 UTC 2021
Maybe the provider is resolved against the platform classloader?
I would think replacing the default provider wasn’t done much before (and not sure if it’s a good idea?). It seems to be good for new form of app sandboxing (but won’t cover old java.io api). So if it only helps for new api consumers, those should allow to specify a base filesystem(root) anyway?
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: nio-dev <nio-dev-retn at openjdk.java.net> im Auftrag von Michael Hall <mik3hall at gmail.com>
Gesendet: Samstag, März 20, 2021 9:16 PM
An: Alan Bateman
Cc: Brian Burkhalter; nio-dev at openjdk.java.net
Betreff: Re: Replacing default FileSystemProvider
The default file system provider is called to create the default file system so your TestProvider's getFileSystem(URI) method is invoked to create the "file:///" file system. It looks like your TestProvider is returning null so I assume this is why you are seeing NPE (assuming TestProvider is representative of the actual file system provider you are using). There is more detail on the javadoc of FileSystem.getDefault().
Getting a bit confusing on the simple test case.
For some reason currently I get ClassNotFoundExceptions on the provider org.test.TestProvider with -cp ./test.jar
I don’t if I fallback to 1.8 or include the current directory with the compiled org/test/*class. Like -cp .:./test.jar
If no obvious suggestions I’ll get back to doing my own debugging against my actual provider.
Thanks for replies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210320/2ff98197/attachment.htm>
More information about the nio-dev
mailing list