This week's java.net Spotlight highlights the Sun Developer Network article "The Java NIO.2 File System in JDK 7", ("NIO" = "New I/O") by Janice J. Heiss and Sharon Zakhour. The Java NIO.2 file system is an OpenJDK implementation of JSR 203. While the JCP currently lists JSR 203 as "inactive", work on the JSR is actually ongoing, under the leadership of Sun's Alan Bateman.

Janice and Sharon define the JSR's "three primary elements that offer new input/output (I/O) APIs for the Java platform:"

• An extensive File I/O API system addresses feature requests that developers have sought since the inception of the JDK.
• A socket channel API addresses multicasting, socket binding associated with channels, and related issues.
• An asynchronous I/O API enables mapping to I/O facilities, completion ports, and various I/O event port mechanisms to enhance scalability.

Their article focuses on the first of these.

One might wonder: why, at this late point in the Java's history, are enhancements to something as fundamental as I/O needed? Janice and Sharon explain:

The Java I/O File API, as it was originally created, presented challenges for developers. It was not initially written to be extended. Many of the methods were created without exceptions, so they failed to throw I/O exceptions, which resulted in considerable frustration for developers. Applications often failed during file deletion, leaving developers confused as to why no useful error message had been generated. The rename method behaved inconsistently across volumes and file systems: Some were easily renamed, but others were not. Methods for gaining simultaneous metadata about files were inefficient. And developers wanted greater access to metadata such as file permissions, as well as more efficient file copy support and file change notification.

Developers also requested the ability to develop their own file system implementations by, for example, keeping a pseudofile system in memory, or by formatting files as zip files.

From this, it's easy to understand the reaction NIO.2 evokes from many developers: statements such as "we've needed this for a long time" and "finally!" In part, it's understandable that extensions to an I/O API will be required, as new types of file systems come into existence. It's a bit more surprising that the original I/O File API was designed without adequate exceptions handling. So, the frustation of developers, and their anticipation of NIO.2, is very much understandable.

"The Java NIO.2 File System in JDK 7" provides overviews of several areas where the NIO.2 APIs will improve the JDK's I/O capabilities:

• The Path Class Operations
• Directories in NIO.2
• The FileVisitor Class Interface -- Developing Recursive Operations
• Symbolic Links
• The WatchService API and File Change Notification
• Two Security Models
• File Attributes and the java.nio.file.attribute Package
• The java.nio.file.spi Package

As Alan Bateman says, in the conclusion of the article:

The file system API will be a significant boon to applications that today are forced to resort to native code to do many basic file system operations. Finally, the platform has support for copying and moving files, symbolic links, and file permissions, and for many other basic features whose previous absence inhibited effective access to the file system.

Some additional JSR 203 resources:

• Elliotte Rusty Harold's java.net article "The Open Road: java.nio.file"
• "New I/O in JDK 7", a GoogleTechTalk by Alan Bateman and Carl Quinn
• Alex Miller's Some JSR 203 Examples