Bringing all file operations together into one place

[Rémi Forax]

On 01/11/2011 10:12 PM, 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

First, I think this version of the API easier to use.

Some comments about java.nio.file.Files:

readAttributes(Path  <http://openjdk.java.net/projects/nio/javadoc/java/nio/file/Path.html>  path,String  <http://download.java.net/jdk7/archive/b123/docs/api/java/lang/String.html?is-external=true>  attributes,LinkOption  <http://openjdk.java.net/projects/nio/javadoc/java/nio/file/LinkOption.html>... options)


should returns a Map<String,Object> if possible.
Map<String,?> will let users deal with wildcard capture.
As an exercise, try to find the type XXX in this code:
XXX entrySet = readAttributes(path, attributes, options).entrySet();

readLines: why not returning a lazy Collection instead of a List.
if a user want a List, this code
List<String> lines = new ArrayList<>(Files.readLines(...))
Or perhaps better, wait jdk 8 and the stream API.

readBytes() can be renamed to readAllBytes().

write(...): javadoc should also contains an example showing how to 
create a new File:

Files.write(path, bytes, StandardOpenOption.CREATE, StandardOpenOption.TRUNCATE_EXISTING, StandardOpenOption.WRITE);

because I'm sure that users will forget TRUNCATE_EXISTING.


Rémi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110113/11b4c03b/attachment.html