Bringing all file operations together into one place
forax at univ-mlv.fr
Wed Jan 12 15:41:26 PST 2011
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  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!
>  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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nio-dev