Legacy java.io.File and new FileSystems

[Alan Bateman]

Michael Hall wrote:
> :
> I'll take a look. From what I 've seen of the project FileSystem demo 
> it appeared to be read only. I don't see where that demo is included 
> in my current bsd-port download. I had run across it before and went 
> looking for the pieces but ended up pulling different parts from 
> changesets or whereever I ran across them. Possibly why it seemed 
> buggy in that the Sanity test failed on the copyTo correctly 
> indicating that the FileSystem was read only. But the demo is what I 
> am looking at for an example to retool my own to jdk7.
Yes, the demo zip provider is currently read-only. The Sanity test 
copies a file from a zip file system to the regular file system so I'm 
not sure how it failed for you (maybe you modified it?). There have been 
a number of patches on nio-dev to fix several issues with the zip 
provider. I can't say if these fix the other issues that you ran into. 
In any case, I should say that we don't currently ship the zip provider 
in the JDK. It's in the nio/nio/jdk repository but needs a bit more work 
to bring it up to a standard that we could include.

>
> :
> Not sure I'm understanding this but maybe that will come as I work 
> with this. If you are saying the getFileSystem is still an all or 
> nothing proposition either the platform one or a single one then you 
> are still limiting the potential for this feature. You would at least 
> want to be able to dispatch to either of these depending on whatever 
> condition, like being or not being in a zip file. Or the custom ones 
> will have to be written smart enough to delegate to the platform when 
> they aren't interested. Maybe the 'scheme' amounts to this?
A FileSystemProvider is identified by a URI scheme ("file", "vfs", 
"memory", "desktop", "zip" for example). The provider is a factory that 
creates FileSystem objects. The default provider is identified as "file" 
and creates a single FileSystem object that we know as the default 
FileSystem. Some providers, such as a "vfs" or "desktop" provider may 
also only create a single FileSystem. Other providers, say "memory" or 
"zip" may create several FileSystem objects, one per memory file system 
or zip file for example. FileSystem objects are factories themselves and 
they create Path, FileStore, WatchService, etc. objects that are 
associated with the FileSystem. When you invoke getFileSystem then it 
simply returns a reference to the associated FileSystem.

If I understand your questions correctly, I think you are mostly 
interested in a virtual file system provider where there is some 
compound path syntax and a single hierarchy, a bit like the native 
virtual file system.  The provider mechanism can be used for this and 
such a provider could create a FileSystem that delegates to other 
FileSystem objects, including the default FileSystem and zip file 
systems. That would be fun project to do. With such a FileSystem then 
the getFileSystem method would return a reference to this virtual file 
system (not the underlying FileSystem).  Out of the box, the default 
provider that we have in jdk7 is not a virtual file system provider. It 
simply creates a FileSystem that provides access to the same file system 
that native applications see.  The API allows the default provider to be 
replaced and also supports providers that want to layer themselves over 
the default provider. You'll find the details in the javadoc.

Hope this helps,

-Alan.