Replacing default FileSystemProvider

[Bernd Eckenfels]

Hello Michael,

If your App expects additional attributes it could be custom enough to request custom provider, it seems like you don’t need to replace the system wide default, which is easier.

I am not sure if it is easy to stay within a filesystem provider, but I expect as long as the app does not repeatingly resolve file URLs that should work.. (with Apache VFS that would be harder)

Do you have a simple reproducer sample for testing?

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: Michael Hall <mik3hall at gmail.com>
Gesendet: Sonntag, März 21, 2021 12:30 AM
An: Bernd Eckenfels
Cc: nio-dev at openjdk.java.net
Betreff: Re: Replacing default FileSystemProvider



> On Mar 20, 2021, at 5:24 PM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
>
> 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?
>

The idea wasn’t to completely replace the default ‘file’ provider but to expose some native API’s through nio attributes. The main use I am remembering. For other purposes it served as a passthrough to the usual default.

So for the FileManager replacement that was being discussed earlier there could be…

        Files.setAttribute(p, "mac_finder:type", new String(b));
        pokeInt(b,0,creator);
        Files.setAttribute(p, "mac_finder:creator", new String(b));

mac_finder would be the API concerned followed by the attribute.
I had attributes for 3 or 4 native API’s.

I have found there does seem to be something version related going on at least…

/usr/libexec/java_home -v 1.8 --exec java -cp .:outputdir/HalfPipe.app/Contents/app/macnio2.jar -Djava.library.path=outputdir/HalfPipe.app/Conents/app -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider Test
class us.hall.trz.osx.MacFileSystem
(base) Michaels-MacBook-Pro:halfpipe_jpkg mjh$ /usr/libexec/java_home --exec java -cp .:outputdir/HalfPipe.app/Contents/app/macnio2.jar -Djava.library.path=outputdir/HalfPipe.app/Contents/app -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider Test
Exception in thread "main" 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
        at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:133)
        at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:102)
        at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:100)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
        at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:100)
        at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.<clinit>(FileSystems.java:94)
        at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:182)
...

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