My examples for JSR 203 were focused on the basics but I was really just skimming the surface of a pretty large set of classes. I’ve had some follow up discussions with Alan Bateman, the spec lead for JSR 203, since my post this week and he called out a list of features that may also be of interest if you want to go deeper. It seemed like a great list so I’m reposting here with his permission:

• Support for symbolic links. Believe or not, this has an implication for every method that accesses the file system.
  
• Files#probeContentType to get the MIME type. This is integrated with the platform MIME database (GNOME, the registry, etc.).
  
• The attribute package is a talk on its own but one useful thing to try out is creating a file with initial permissions (to avoid the window that otherwise arises when creating a file and immediately setting its permissions). There are lot of other security features in this API as well.
  
• Some of the open options may be interesting. For example, the DELETE_ON_CLOSE option is going to be useful to some people.
  
• A Path preserves the platform representation of the platform (for example on Linux or Unix this means bytes). Create files in a directory when under a different locale and you may find that you can’t access them with java.io.File. However, iterate over the directory with Path#newDirectoryStream and you should see that you can access the files (because the byte representation is preserved; in java.io.File it gets lost when converting the file name to a String).
  
• For random access to files then it may be good to point out SeekableByteChannel. For concurrent access to files then AsynchronousFileChannel may be interesting (this is in the channels package but the factory for AsynchronousFileChannels is the FileSystemProvider).
  
• One other thing that is probably worth pointing out is the File#toPath method. This allows you to get an object in the new API from existing code that is using java.io.File. For
  example, suppose you have code that does f.delete(). You can change this to f.toPath.delete() so that you get a reasonable exception when the delete fails.

I should also mention that the new file system API is actually only part of what’s covered in JSR 203. Additionally, there’s a completion of many of the APIs started in the prior incarnation of NIO, with full support for multicast, and support for asynchronous I/O on both sockets and files.

From http://tech.puredanger.com