Legacy java.io.File and new FileSystems

[Michael Hall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Aug 11, 2010, at 3:56 AM, Alan Bateman wrote:

>  but having the java.io classes redirect is probably good enough  
> for most cases.

All right. This is what I wasn't clear on. If the legacy would be  
able to redirect to the custom new FileSystems. If so, fine.
>
>>
>> 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

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.

>
>>
>> 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.

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?
I guess I have a little trouble giving up on my own idea but  
dispatching code doesn't seem that difficult to implement. It  
wouldn't need to be in File. I think it was for me, deciding whether  
to pass the request to a zip instance or 'primordial' but it wouldn't  
need to be. You have the getFileSystem method which seems very apt to  
be converted into some sort of factory invocation. But again maybe  
the 'scheme' or something similar addresses this and I'll figure it  
out as I look at it.

I am just happy with the reassurance now that legacy File isn't  
completely locked out of the possibility to use the new FileSystems.

Thanks,

Mike Hall        hallmike at att dot net
http://www195.pair.com/mik3hall
http://www195.pair.com/mik3hall/home.html
http://sourceforge.net/projects/macnative




-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iJwEAQECAAYFAkxifpIACgkQUvk/ZSaThTKvOAQAxrBuVfv6bqIC0oidMjs8n4fd
QnnalxPaLBrVDr6gxitswZgb1Tr8BLSMAs6EiKe8tJY3NIspLJzvGuTiQZdNfeEo
2dM4FgMUmoUO4mpkI1152Nh1lQc6vFM+BMcfA6V3PfcVvl2a7uFMbR9uJVZom9sF
IiuOmUp/v+Bvv5TLLAI=
=hJuF
-----END PGP SIGNATURE-----