JGenFile Java Generic Filesystems

Latest Version:
JGenFile 1.0 alpha


Why does the java.io.File way of accessing the file system need improvement?
Why is JGenFile cenetered around operations?

Why does the java.io.File way of accessing the file system need improvement?

Most people that have worked with file I/O in Java will have used the java.io.File class. It is 'an abstract representation of file and directory pathnames', allowing platform independent access to the file system.

Firstly, the java.io.File class does not work with paths consistently on different platforms. File separators are the problem, on Windows the separator is the backslash, on 'nix it is the forward slash. Even if you are careful and use the File.SEPARATOR variable instead of hardcoding it in file names, problems arise when you, for example, store the path in a configuration file. Something trivial like accessing the file 'hello.txt' in the parent directory can be written different ways depending on the platform (../hello.txt vs ..\hello.txt). So, if the application is ported to another platform, the configuration file will have to be rewritten with the appropriate separator characters. There are ways around this but they are messy and cumbersome. The problem is that a java.io.File object is basically a wrapper around a String representation of a path instead of a true path of many File objects.

Secondly, a lot of file and file system information is simply not accessible through the java.io.File class. File attributes, such as permissions in Linux , and the 'last accessed' date on Windows cannot be retrieved or modified through java.io.File.

Thirdly, many methods in java.io.File do not throw exceptions when they fail. For example, the delete() method returns true or false depending on if the deletion succeeded. What should happen (in my opinion) is that an exception is thrown if the deletion fails, perhaps conveying information as to why it failed.

JGenFile covers these issues, and also adds additional functionality, most notably the ability toaccess different file systems, such as FTP.

Why is JGenFile cenetered around operations?

At first glance, performing everything through operation objects can make JGenFile seem more complicated. It would certainly require less code to do everything by getting the result straight back from a method call instead of creating an operation and running it. But operations offer a number of advantages over the straight method call approach.

Operations allow additional information to be returned. Information such as the progress of an operation can be returned since an operation is an object. This also means that additional things can be added to operations in future versions without breaking old code. For example, the CanDeleteItemOperation could be extended to contain a reason why a file cannot be deleted in a future version of JGenFile.

Operations can be 'batched', that is run at the same time to improve performance. This is not so much of an issue for the local file system, but for other file systems batching is necessary for writing high performance applications. Take a ZIP file for example. Every time a file is deleted from a ZIP file, the entire ZIP needs to be rewritten. Without batching, deleting 200 files from a ZIP file would require it to be rewritten 200 times! But if the 200 delete operations are batched, the ZIP file only needs to be rewritten once.

Most people will only be interested in getting access to a file at a time through JGenFile, which required running only a few operations in one or two parts of their program. Those of us that use the file system more extensively (such as when writing a file manager application) will probably want to write code that runs efficiently anyway.