This specification is intended to become part of the Java Standard Edition, version 7 ("Dolphin").

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

This JSR will be delivered as part of Java SE 7 "Dolphin".

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

The terms will be the same as those for Java SE 7, which are broadly the same as those of Java SE 6.

2.11 Please describe the anticipated schedule for the development of this
specification.

TBD

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

This specification is intended to become part of the Java 2 Platform, Standard Edition, version 1.5 ("Tiger") as specified by JSR 176.

2.3 What need of the Java community will be addressed by the proposed specification?

The proposed specification will satisfy several needs of the Java community:

1.
The Java platform has long needed a filesystem interface better than the java.io.File class. That class does not handle filenames in a way that works consistently across platforms, it does not support efficient file-attribute access, it does not allow sophisticated applications to take advantage of filesystem-specific features (e.g., symbolic links) when available, and many of its methods simply return false on error instead of throwing an informative exception.

2.
The primary goal of JSR-51, the first New I/O JSR, was to provide primitives for scalable I/O so that performance-critical programs such as web and application servers could be written without having to resort to native code. The multiplexed, non-blocking facility introduced by JSR-51 solved much of that problem for network sockets, but it did not do so for filesystem operations. It has, moreover, recently become apparent that the next generation of high-performance network controllers and operating-system I/O interfaces may be better served by an asynchronous rather than a multiplexed API.

3.
Since the completion of JSR-51 and the release of J2SE 1.4, its reference implementation, developers have noted the clumsiness of the current relationship between java.nio.channels socket channels and java.net sockets, the latter still being required for socket-specific operations such as binding and configuration. Developers have also asked about the lack of support in the java.nio.channels package for multicast datagrams.

2.4 Why isn't this need met by existing specifications?

Much of the functionality required to meet the above needs is simply not present in the latest version of J2SE. Currently developers must write significant amounts of platform-dependent code, some of it native, in order access such functionality in the underlying operating system.

2.5 Please give a short description of the underlying technology or technologies:

All three of the proposed components will rely heavily upon services provided by the underlying operating system and hardware platform, so some native code will be required. As in JSR-51, we hope to keep the amount of native code required to a minimum.

Aside from these components, we expect the bulk of an implementation will be pure Java code. Some of this code will of necessity be platform-specific, but most of it will be completely portable.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

JSR-51 defined the new package java.nio, the subpackages java.nio.channels and java.nio.charset, and two related service-provider (.spi) subpackages. We envision creating one more new subpackage for the filesystem interface along with a corresponding service-provider subpackage; we expect the remainder of this work to fit naturally into the existing java.nio packages.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

The design of the new APIs will be influenced heavily by the capabilities of the native APIs of a wide variety of systems. The resulting APIs are, however, intended to be completely platform independent.

2.8 Are there any security issues that cannot be addressed by the current security model?

No. Some new permissions will likely be defined, but the current security model is more than adequate.

2.9 Are there any internationalization or localization issues?

The new filesystem interface will need to take special care to ensure that file names encoded in arbitrary character sets can be handled. We otherwise forsee no significant internationalization or localization issues.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

We do not propose to deprecate the current java.io.File class, but we do hope that most developers will eventually migrate to the new filesystem interface.

2.11 Please describe the anticipated schedule for the development of this
specification.

July 2003 -- Community Review
October 2003 -- Public Review
January 2004 -- Proposed Final Draft

The final release of this specification will be coincident with that of the containing J2SE 1.5 "Tiger" release.

2.12 Please describe the anticipated working model for the Expert Group working on developing this
specification.

We anticipate working primarily via e-mail. This worked well for the JSR-51 Expert Group.

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.