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?

Tridimensional

Speculation: FileVisitor may also be usable to access other file systems, e.g. HDFS. – Memling

Answer 1

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);
    }
}

Infectious

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 Files. – Tridimensional

Answer 2

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.

Yonne

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<ZipEntry> will require some sophisticated logic since ZIP file structure as provided by ZipInputStream is flat and may not contain entries in correct order. – Tridimensional

@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. – Yonne

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