Replacing default FileSystemProvider

[Michael Hall]

> On Mar 20, 2021, at 2:48 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 19/03/2021 21:09, Michael Hall wrote:
>> :
>> 
>> I had hoped for something obvious I missed.
>> 
>> If it will require looking into the complete simple test case is here…
>> 
>> http://mikehall.pairserver.com/testfsp.zip <http://mikehall.pairserver.com/testfsp.zip>
>> 
> 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().

The original MacFileSystemProvider had this…

    @Override
    public FileSystem getFileSystem(URI uri) {
       if (uri.getScheme().equals(scheme))
    		return new MacFileSystem(this,priorProvider);
       else return priorProvider.getFileSystem(uri);
    }

So it shouldn’t be the error with that. I’ll try to improve the TestProvider so this is not the error. 
And verify the errors are the same although I think they were still pretty similar. Not able to do that immediately.

> 
> One of your mails mentions that you have a replacement for com.apple.eio.FileManager. Can you say more about this? Are you the submitter of JDK-8187981[1] ? That issue is looking for improve macOS/desktop integration but it pre-dates several APIs on java.awt.Desktop and other features, maybe it can be closed?
> 
> -Alan.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8187981

I may of submitted that bug report. I certainly added to it. Having com.apple.eio.FileManager inaccessible at jdk 16 sort of escalates matters. I assume it’s still there somewhere because the error indicated that the Desktop module didn’t export it.  java.awt.Desktop currently does replace a lot of the major functionality FileManager had. But not some of the more Mac specific sort of lower level stuff. I did the replacement probably back around macports time. So it’s been around probably about as long as the bug report. As long as the JDK continued to provide the original it was sort of moot. 
For my use yes the replacement I did should suffice. Based on what Apple provided for macports it is in fact partially the original. I replaced some parts based on the MacFileSystemProvider I did. If that worked it should work for about anyone pretty much as the original did. I can certainly have that on GitHub. But there is obviously a difference in me providing it and the JDK providing it. 

Your risk would be others code failing who don’t know about a replacement. If that merits keeping the bug report open would be up to you. Like having it available in the first place.

Enough of the replacement worked without the FileSystemProvider so that my application works. The same code of mine included in the bug report I think. The FileSystemProvider part working if I was going to claim it as a true replacement would be nice.