<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 01/11/2011 10:12 PM, Alan Bateman wrote:
    <blockquote cite="mid:4D2CC7CB.7090301@oracle.com" type="cite">
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      Feedback welcome!
      <br>
      <br>
      -Alan
      <br>
      <br>
      [1] <a class="moz-txt-link-freetext" href="http://openjdk.java.net/projects/nio/javadoc">http://openjdk.java.net/projects/nio/javadoc</a>
      <br>
    </blockquote>
    <br>
    First, I think this version of the API easier to use.<br>
    <br>
    Some comments about java.nio.file.Files:<br>
    <pre>readAttributes(<a href="http://openjdk.java.net/projects/nio/javadoc/java/nio/file/Path.html" title="interface in java.nio.file">Path</a>&nbsp;path, <a href="http://download.java.net/jdk7/archive/b123/docs/api/java/lang/String.html?is-external=true" title="class or interface in java.lang">String</a>&nbsp;attributes, <a href="http://openjdk.java.net/projects/nio/javadoc/java/nio/file/LinkOption.html" title="enum in java.nio.file">LinkOption</a>...&nbsp;options)

</pre>
    should returns a Map&lt;String,Object&gt; if possible.<br>
    Map&lt;String,?&gt; will let users deal with wildcard capture.<br>
    As an exercise, try to find the type XXX in this code:<br>
    XXX entrySet = readAttributes(path, attributes, options).entrySet();<br>
    <br>
    readLines: why not returning a lazy Collection instead of a List.<br>
    if a user want a List, this code <br>
    List&lt;String&gt; lines = new
    ArrayList&lt;&gt;(Files.readLines(...))<br>
    Or perhaps better, wait jdk 8 and the stream API.<br>
    <br>
    readBytes() can be renamed to readAllBytes().<br>
    <br>
    write(...): javadoc should also contains an example showing how to
    create a new File:<br>
    <pre>Files.write(path, bytes, StandardOpenOption.CREATE, StandardOpenOption.TRUNCATE_EXISTING, StandardOpenOption.WRITE);
</pre>
    because I'm sure that users will forget TRUNCATE_EXISTING.<br>
    <br>
    <br>
    R&eacute;mi<br>
    <br>
  </body>
</html>