Legacy java.io.File and new FileSystems

Alan Bateman Alan.Bateman at oracle.com
Thu Aug 12 01:30:22 PDT 2010


Michael Hall wrote:
> :
> Exception in thread "main" java.nio.file.ReadOnlyFileSystemException
>     at com.sun.nio.zipfs.ZipFilePath.copyTo(ZipFilePath.java:1132)
>     at Sanity.main(Sanity.java:92)
>
>     @Override
>     public Path copyTo(Path target, CopyOption... options) {
>         throw new ReadOnlyFileSystemException();
>     }
>
> Again this might be because of how I pieced the thing together with 
> Google searches for missing classes and grabbing the source out of the 
> browser.
> The current version might not have this.
I can't really tell which version of the zip provider you are looking 
at. The mercurial repository to clone is 
http://hg.openjdk.java.net/nio/nio/jdk and the zip provider is in 
src/share/demo/nio/ZipFileSystem/com/sun/nio/zipfs directory. I checked 
the history of ZipFilePath and its copyTo method has had an 
implementation since May 2009 so you must be looking at an old version.


> :
> I'll check the doc, various, and see where I go from there. I'll read 
> through your post a little more closely first, it may explain a lot of 
> what I'm not understanding. What I'm looking for again is more or less 
> what I had thrown together before myself. A custom FileSystem that 
> will work without modification with existing File/FileOutputStream 
> based java.  If the existing code requires modification, that is less 
> ideal but still makes custom FileSystems and java.io based code 
> something that could be done. The example again is that you can take 
> something like javac and get it to use a custom FileSystem without any 
> changes to it at all. Generalizing this could any other existing java 
> package/library/application. You can get them to use some FileSystem 
> just by snapping it on. Remembering this may be code you are not 
> otherwise free to modify and the scope may be of enough complexity you 
> wouldn't want to put in the effort to modify it even if you are in a 
> position to do so. The code should be pointed at the custom FileSystem 
> without changing it and just work.
As I said, in this API, the way to get existing apps using 
java.io.File/etc. to access these custom file systems transparently is 
to develop a virtual file system provider and run with it set as the 
default. A fun project if you have the time to work on it.

-Alan.


More information about the nio-discuss mailing list