Why is NIO.2 FileVisitor type generic?

Question

I'm doing some research on Java NIO.2 and its file operations, and currently I'm playing with filetree-walking functions and classes.

NIO.2 FileVisitor API is wonderful, it's a shame that such thing has been added to Java SE only recently, not ten years ago. However, there is something which slightly bothers me: what is the point of making FileVisitor interface generic?

Every single example on the net shows how to use it with Files.walkFileTree() which implies that we are using FileVisitor<Path> type. But I just cannot see any use for this interface for things other than Path. Well, it may be possible to use FileVisitor to walk other kinds of trees (in-memory ones?), but this just doesn't feel right: this interface and related classes have very specific names semantically tied to files, and also FileVisitor's methods throw IOExceptions.

So, were there any reasons for parameterizing FileVisitor type?

Speculation: `FileVisitor` may also be usable to access other file systems, e.g. [HDFS](http://en.wikipedia.org/wiki/HDFS#Hadoop_Distributed_File_System). — ValarDohaeris, May 06 '13 at 20:56

OldCurmudgeon · Answer 1 · 2013-05-06T22:38:35.567

5

Do you use GitHub? This would be a perfect opportunity to use the FileVisitor to implement an API to GitHub that allows you to explore/visualise GitHub projects. For that matter almost any SCC system could make use of a different class as the file locator

And how about using a FileVisitor<ZipEntry> for traversing zip files.

If an API is potentially usable with multiple objects as its target it just makes sense to make it generic. I think not making it generic would be the mistake that should be considered foolish.

edited May 06 '13 at 22:38

answered May 06 '13 at 22:03

OldCurmudgeon

64,482
16
119
213

Thanks, VCSes really are very good example of `FileVisitor` application. However, `FileVisitor` interface really looks half-generic; yes, it is parameterized by *path* type, but why it is also not parameterized by *attributes* type? It uses `BasicFileAttributes` always. `IOException` also seems kinda limiting. And also `FileVisitor` will require some sophisticated logic since ZIP file structure as provided by `ZipInputStream` is flat and may not contain entries in correct order. – Vladimir Matveev May 06 '13 at 22:12
@VladimirMatveev - What attributes would you present from a Mercurial/Git/SVN VCS? Wouldn't it be significantly different from an HFS? Also, zip files are not at all flat. You can have the equivalent of directories in zips - they are zip files. Zip a zip file in a zip and you have the equivalent of a folder. – OldCurmudgeon May 06 '13 at 22:37
Well, VCS filesystems may provide revisions information for each file, diffs, change logs etc - this all is metainformation, isn't it? And zip files inside zip files are really weird, never met them in practice. AFAIK all current archivers represent directories as paths separated by slashes. This does not ruin the example, though, such archives really can model the filesystem. – Vladimir Matveev May 07 '13 at 10:10

score 5 · Accepted Answer · answered May 06 '13 at 22:04

With generics the same interface can be used for other types of paths. As shown in the following (simplified) code fragment, the interface works nice with java.io.File:

FileVisitResult walk(File file, FileVisitor<File> visitor)
    throws IOException
{
    if (file.isDirectory()) {
        visitor.preVisitDirectory(file, null);
        for (File child : file.listFiles()) {
            walk(child, visitor);
        }
        return visitor.postVisitDirectory(file, null);
    } else {
        return visitor.visitFile(file, null);
    }
}

Yeah, that's exactly what I thought about several minutes after I have written the question, that it is possible to apply `FileVisitor` to regular `File`s. — Vladimir Matveev, May 06 '13 at 22:07

Why is NIO.2 FileVisitor type generic?

2 Answers2