Legacy java.io.File and new FileSystems

[Alan Bateman]

Michael Hall wrote:
> :
> As you say you have a getFileSystem() method here that is pretty much 
> unnecessary. It simply invokes the one and only platform FileSystem. 
> Why not make this make a dispatcher that based on some mechanism 
> dispatches the File instance to the correct 'logical' FileSystem.
There may be several FileSystem instances (custom FileSystems in 
addition to the default FileSystem) so the getFileSystem method is needed.

The reason that java.io.File is not simply a dispatcher by default is 
because of compatibility, startup performance, and modularity concerns.  
The compatibility concerns arise due to the long standing odd, and 
sometimes very broken, behavior that would change. The startup concern 
arise because there would be additional classes loaded/initialized 
during startup and that is something that is tracked very closely.  So 
we've been down this road already and the solution that seems to work 
best is to keep existing File behavior by default and to have File, and 
the java.io classes delegate to the default file system for the case 
that the default provider is something other than the system default. 
There are a few areas (such as java.util.zip) that aren't as clear 
because they use memory mapped I/O but having the java.io classes 
redirect is probably good enough for most cases.

>
> I did implement something similar, it provided a zip based FileSystem 
> by substituting for the involved java.io core classes. I had a System 
> property that could be set, zip + <filename> = true
> or something close to that.
> Using this I could do javac compiles without any changes to javac 
> where it would write it's output to a zip file transparently unaware 
> that it's File's and FileOutputStreams were doing anything different.
That sounds like a fun project. 

See also this blog where Jon Gibbons talks about using the file system 
API with javac. I believe this works with the demo zip provider too.
   http://blogs.sun.com/jjg/entry/jsr_199_meets_jsr_203

>
> If of interest to anyone, Transparent Random Zip
> http://www195.pair.com/mik3hall/javasrc.html#trz
> I am retooling this to work with jdk7 FileSystems. 1.6 pretty much 
> busted it.
>
> The point though is that if you don't already allow this it seems to 
> me that allowing FileSystem dispatching would be an enhancement in 
> allowing legacy code to work transparently without retrofitting. 
> Making the new FileSystems more universal and useful.  There are a lot 
> of existing File only programs out there.
As I said, java.io.File wasn't really designed for this. If you want use 
the existing APIs to access files in custom file systems then it 
requires running with the default provider set to your own virtual file 
system provider.  That way you can use compound names or special path 
syntax to locate files in these file systems. One thing to remember is 
doing this may cause interoperability issues with native applications 
that won't understand this path or URI syntax.

-Alan.