Alex Miller lives in St. Louis. He writes code for a living and currently work for Terracotta Tech on the Terracotta open-source Java clustering product. Prior to Terracotta he worked at BEA Systems and was Chief Architect at MetaMatrix. His main language for the last decade has been Java, although Alex have been paid to program in several languages over the years (C++, Python, Pascal, etc). Alex has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Some More JSR 203 Examples

10.28.2008
| 7735 views |
  • submit to reddit

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

Published at DZone with permission of its author, Alex Miller.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)