Legacy java.io.File and new FileSystems

[Alan Bateman]

Michael Hall wrote:
> :
>
> What I had been thinking was that java.io.File support would go 
> something like FileSystem.getFileSystem gets a instance for the 
> platform or custom FileSystem, whichever it is. But since there are 
> slight differences between io.FileSystem and nio.FileSystem like the 
> getBooleanAttributes usage then this wouldn't work for anything like 
> the exists() method I was testing with.
> For exists() you could test if a custom provider was in effect, 
> meaning nio, and then do what was successful for me. toPath().exists() 
> and what getFileSystem had returned wouldn't matter.
> Although I haven't verified that there is an equivalent Path method 
> for each File method I'm assuming so.
> Then File support might better be something like...
>
> package java.io;
>
> public class File {
>
> public boolean exists() {
>     SecurityManager security = System.getSecurityManager();
>     if (security != null) {
>         security.checkRead(path);
>     }
>     if (custom)        // Was a custom nio FileSystemProvider indicated?
>         return toPath().exists();
>     // No use platform 'io' provider
>     return ((fs.getBooleanAttributes(this) & FileSystem.BA_EXISTS) != 0);
> }
>
> all done? Any differences in the FileSystem API's io to nio don't 
> matter as long as File and Path aren't different.
That would work too and amounts to the same thing. In our implementation 
there is a java.io.FileSystem implementation that delegates to the new 
API. The other classes 
(FileInputStream/FileOtputStream/RandomAccessFile) require redirecting 
along the lines that you doing (necessary because they have public 
constructors).

-Alan