The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 203

This JSR is being developed as an OpenJDK project here.

Updates to the Original Java Specification Request (JSR)

Note that the following information represents updates to the original JSR.

2006年01月30日:

2.1 Please describe the proposed Specification:

The proposed specification will continue the work of defining a set of new and improved I/O APIs that was started in of JSR-51: New I/O APIs for the Java Platform. Its major components will be:

1. A new filesystem interface that supports bulk access to file attributes, change notification, escape to filesystem-specific APIs, and a service-provider interface for pluggable filesystem implementations;

2. An API for asynchronous (as opposed to polled, non-blocking) I/O operations on both sockets and files; and

3.The completion of the socket-channel functionality defined in JSR-51, including the addition of support for binding, option configuration, and multicast datagrams.

The specification may contain additional enhancements deemed desirable by the expert group and within the scope of the containing release.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

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.

---

2005年08月10日:

Section 1. Identification

Specification Lead: Alan Bateman

E-Mail Address: alan.bateman@sun.com

Telephone Number: +353 1 819 9142

Fax Number: +353 1 819 9200

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This specification is intended to become part of the Java 2 Platform, Standard Edition, version 6.0 ("Mustang").

NOTE that this information has been updated from this update.

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 JSR will be delivered as part of J2SE 6.0 "Mustang".

NOTE that this information has been updated from this update.

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 J2SE 6.0, which are broadly the same as those of J2SE 1.4.

NOTE that this information has been updated from this update.

---

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Sun Microsystems, Inc.

Name of Contact Person: Mark Reinhold

E-Mail Address: mr@sun.com

Telephone Number: +1 408 276 7256

Fax Number: +1 408 276 7700

Specification Lead: Mark Reinhold

E-Mail Address: mr@sun.com

Telephone Number: +1 408 276 7256

Fax Number: +1 408 276 7700

Note that this information has been updated from this original JSR.

Initial Expert Group Membership:

TBD

Supporting this JSR:

Apple Computer
Doug Lea
Sun Microsystems, Inc.

Section 2: Request

2.1 Please describe the proposed Specification:

Note that this information has been updated from this original JSR.

The proposed specification will continue the work of defining a set of new and improved I/O APIs that was started in of JSR-51: New I/O APIs for the Java Platform. Its major components will be:

1. A new filesystem interface that supports bulk access to file attributes, escape to filesystem-specific APIs, and a service-provider interface for pluggable filesystem implementations;

2. An API for asynchronous (as opposed to polled, non-blocking) I/O operations on both sockets and files; and

3.The completion of the socket-channel functionality defined in JSR-51, including the addition of support for binding, option configuration, and multicast datagrams.

The specification may contain additional enhancements deemed desirable by the expert group and within the scope of the containing release.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Note that this information has been updated from this original JSR.

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.

Note that this information has been updated from this original JSR.

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.

Note that this information has been updated from this original JSR.

This JSR will be delivered as part of J2SE 1.5 "Tiger".

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.

Note that this information has been updated from this original JSR.

The terms will be the same as those for J2SE 1.5, which are broadly the same as those of J2SE 1.4.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

The JSR-51 (New I/O) Specification, which is part of the J2SE 1.4 platform specification.

3.2 Explanation of how these items might be used as a starting point for the work.

As mentioned above, the APIs proposed here are expected to fit into the overall conceptual framework defined by JSR-51.