AW: Implementing a FileSystemProvider

[Christian Schlichtherle]

Hi Alan,

 

so in clear words, if I do NOT provide an implementation for the "file"
scheme, I can safely use java.io.File* in my FileSystemProvider?

 

This would make it a lot easier for Michael and me to complete the work on
this subject. We could then use TrueZIP's TFile class - which inherits from
File - in order to do the scanning for archive files in a path.

 

Regards,

Christian

 

Von: Alan Bateman [mailto:Alan.Bateman at oracle.com] 
Gesendet: Dienstag, 24. Mai 2011 22:09
An: christian at schlichtherle.de
Cc: nio-discuss at openjdk.java.net
Betreff: Re: Implementing a FileSystemProvider

 

Christian Schlichtherle wrote: 

Hi Alan,

 

now that I've released TrueZIP 7.1 (http://truezip.java.net), I have finally
some time to look into the FileSystemProvider implementation.

 

I wonder if it's OK for a java.nio.file.spi.FileSystemProvider
implementation to use the java.io.File* classes or if this might create a
recursion? If not OK, which conditions could lead to a recursion then?

 

I recall from our conversations some time ago that federation is not
supported in JSE 7. I take from this that File* classes never look up a
FileSystemProvider and therefore it should be safe to use File* in a
FileSystemProvider implementation. Is this correct?

 

Regards,

Christian

It should be okay for providers that implement URI schemes other than
"file". 

However if you want your provider to be the default provider (implementing
the "file" scheme) then it would be problem if the provider used
java.io.File (or any of FileInputStream, FileOutputStrea, or
RandomAccessFile). While it will work now it is unlikely to work in the
future as these classes should redirect to the default provider when it is
overridden. There is code in place to detect recursive attempts to
initialize the default provider but there is nothing except a stack overflow
that would arise if you invoked a method on java.io.File that delegated to
the default provider.

-Alan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20110524/0592a53d/attachment.html