Bringing all file operations together into one place

[Wolfgang Baltes]

On 2011-01-11 13:12, Alan Bateman wrote:
>
>
> One of the things that I've been looking at recently is the file
> system API and to see how it might evolve in the future, post jdk7.
> One confusing thing is that the file operations are currently split
> over several classes. At it stands, if a file operation requires new
> support from the provider implementation then it is added to the Path
> class, if it is independent of the provider it can be defined by the
> Files class, file attribute helper methods are defined by the
> Attributes class. This needs to be cleaned up so that it's clear and
> obvious where to add new file operations in the future. To that end, I
> have an update to the API [1] that moves all the file operations into
> the Files class and removes the Attributes class. For the most part,
> the methods defined by Files just delegate to the FileSystem
> associated with the Path or are implemented in terms of other methods.
> The alternative moves everything to Path but that is much less
> satisfactory and results in a huge class of path and file operations.
> Another advantage of having Path only define path methods is that it
> opens the possibility of look at interfaces again, esp. with extension
> methods potentially coming in 8.
>
> There are a couple of other small updates too. The
> readXXXFileAttributes methods to read attributes in bulk have been
> replaced with a single readAttributes method that takes a type token
> to specify the required attributes - this is something that Joe Darcy
> suggested. There are also a few new convenience methods for
> simple/common cases.
>
> Feedback welcome!
>
> -Alan
>
> [1] http://openjdk.java.net/projects/nio/javadoc
>
>
For what its worth, my opinion is that this is a good change. Besides 
your arguments with which I agree, I observe more consistency as a 
result of the change. Maybe this wasn't the purpose, but I like the 
outcome that because almost all methods of the new Path interface deal 
with the abstract path concept, they don't require physical access 
authority, nor will they throw IOException or SecurityException (there 
are a few exceptions such as toURI, toAbsolutePath, toRealPath, and 
register). Conversely, all Files methods deal with physical access, and 
therefore require authority, and possibly throw the exceptions mentioned.

Wolfgang.