From Pain to Gain: Swing and the NetBeans Platform in the Real World

The FileSystem API

Java offers just a bare-bones approach for file management through the java.io.File class, which wraps a file name and provides attribute access, basic operations and directory listing. This approach is really poor, since there’s no concept of a filesystem; furthermore, File objects are bound to local, physical files/directories. What if you need to represent a virtual or remote directory tree? I faced this problem a few years ago, and in the end I solved it by extensively subclassing File – not a neat design, even though it worked.

NetBeans’ FileSystem API fills this gap. There’s a whole set of FileSystem classes that can be used to represent different types of filesystems: local, remote or even virtual. (NetBeans’ inner configuration settings, including those of your custom code, are stored in such a virtual file system.) The only caveat is that you must use a NetBeans-specific instance of FileObject instead of File, but converting one into the other is easy:

FileObject fileObject = ...;
File file = ...;
file = FileUtil.toFile(fileObject);
fileObject = FileUtil.toFileObject(file);

blueMarine has a strict requirement for managing files. Each file must be associated with a unique id stored in a local database. The id is later used to build relationships between each photo and other entities such as thumbnails, metadata, galleries, editing settings, and so on. It’s a rather common design for this kind of application, allowing you to later move or rename photos without too many changes in the database. It also lets you work with remote volumes such as external disks and DVDs. In other words, even when you don’t have the file available in the system, you can look at its thumbnails and metadata.

A good starting point for tweaking the filesystem management is the LocalFileSystem class, which represents a tree of files with a single root (for systems with multi-root hierarchies like Windows you just need to put a few LocalFileSystem objects together).

The LocalFileSystem class includes AbstractFileSystem.Attr and AbstractFileSystem.List. Attr lets you manipulate a set of attributes for each FileObject, and List lets you customize a directory listing. (Attributes are just simple properties which are bound to a FileObject and can be manipulated with getters and setters.)

I started by writing a simple subclass of LocalFileSystem that installs decorators of Attr and List, as shown in Listing 3. The AttrDecorator class retrieves the unique id for each file path (the FileIndexer is just a sort of DAO for this data), and makes it available as a special attribute of FileObject (ID_ATTRIBUTE). The code is shown in Listing 4.

class LocalIndexedFileSystem extends LocalFileSystem {
  public LocalIndexedFileSystem() {
     attr = new AttrDecorator(attr, this);
     list = new ListDecorator(list, this);
  }
}              

class AttrDecorator implements AbstractFileSystem.Attr {
      
   private static final FileIndexer fileIndexer = FileIndexerLocator.findFileIndexer();
   private AbstractFileSystem.Attr peer;
   private LocalIndexedFileSystem fileSystem;

   public AttrDecorator(AbstractFileSystem.Attr peer, LocalIndexedFileSystem fileSystem) {
     this.peer = peer;
     this.fileSystem = fileSystem;
   }

   public Object readAttribute (String path, String name) {
     if (IndexedFileSystem.ID_ATTRIBUTE.equals(name)) {
        String path2 = fileSystem.findCompletePath(path);
        Serializable id = fileIndexer.findIdByPath(path2); 
        if (id == null) {
           fileIndexer.createIndexing(path2, false);
           id = fileIndexer.findIdByPath(path2);
        }
        return id;
     }
     else {
        return peer.readAttribute(path, name);
     }
    }

    ...
    ...
    ...

}

While AttrDecorator would be enough to satisfy the functional specs, there’s still the problem of batch loading. The readAttribute() method would be called quite randomly, thus preventing any effective batch policy (FileIndexer is able to do batching by lazy loading, but to be effective it needs to have a good number of entries to batch!).

Here ListDecorator helps us, as it intercepts children files after they are listed from a parent directory (see Listing 5). Calling createIndexing() immediately on the set of listed files allows the FileIndexer to batch the retrieval of their ids.

class ListDecorator implements AbstractFileSystem.List {

  private static final FileIndexer fileIndexer = FileIndexerLocator.findFileIndexer();
  private AbstractFileSystem.List peer;
  private LocalIndexedFileSystem fileSystem;
 
  public ListDecorator (AbstractFileSystem.List peer, LocalIndexedFileSystem fileSystem)
  {
    this.peer = peer; 
    this.fileSystem = fileSystem;
  }

  public String[] children (String path) {
    String[] result = peer.children(path);
    if (!fileSystem.disableChildrenIndexing) {
    String path2 = fileSystem.findCompletePath(path);
    if (result != null) {
        for (String child : result) {
          fileIndexer.createIndexing(path2 + child, true);
        }
     } 
    }
    return result;
  }

}