• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Specification Leads
	Mark Reinhold	Sun Microsystems, Inc.
Expert Group
	BEA Systems	IBM	Kegel, Dan
	Lea, Doug	NTT	Oki Electric Industry Co., Ltd.
	Oracle	Sabin, Miles	Sun Microsystems, Inc.
	Welsh, Matt

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Participant: Sun Microsystems, Inc.

Name of Contact Person: Mark Reinhold

E-Mail Address: mr@eng.sun.com

Telephone Number: 408-343-1830

Fax Number: 408-343-1797

Section 2: Request

2.1 Please describe the proposed Specification:

The proposed specification will define a set of new and improved I/O APIs for the Java Platform. Its major components will be:

• An API for scalable I/O operations on both files and sockets, in the form of either asynchronous requests or polling;

• An API for fast buffered binary I/O, including the ability to map files into memory when that is supported by the underlying platform;

• An API for fast buffered character I/O, including a simple parsing facility based upon regular expressions and a simple printf-style formatting facility;

• An API for character-set converters, including a service-provider interface for pluggable converters;

• A rich yet platform-independent set of I/O exceptions; and

• A new filesystem interface that supports bulk access to file attributes (including MIME content types), escape to filesystem-specific APIs, and a service-provider interface for pluggable filesystem implementations.

For ease of use the new APIs will leverage the patterns of the existing I/O APIs when appropriate. Full interoperability with the current base stream classes will be supported.

In order to be efficient the new classes will be minimally synchronized, leaving it in nearly all cases for the caller to synchronize when necessary. To make this easy, synchronization "wrappers" similar to those in the Java platform's collections framework may be provided.

Efficiency will also be achieved by introducing a simple buffer-oriented I/O model consisting of basic streams of bytes and characters together with monolithic, highly-tuned classes that combine support for buffering, formatting, and parsing.

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

These APIs are intended to become part of the Java 2 Platform, Standard Edition.

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

The proposed specification will satisfy several long-standing needs of the Java community.

• The scalable I/O API will make it easier to write production-quality web and application servers that scale well to thousands of open connections and can easily take advantage of multiple processors;

• The fast buffered binary I/O API will make it easier to write high-performance, I/O-intensive programs that manipulate streams or files of binary data;

• The fast buffered character I/O API will simplify the efficient handling of character streams and files; it will also bring regular expressions and a compact notation for formatted output to the Java platform, putting it on a par with other popular platforms such as Perl;

• The character-set converter API will give developers direct access the platform's built-in character-set converters and will also provide for the easy "plugging in" of new converters;

• The new set of I/O exceptions will make it easier to write programs that recover from different types of I/O failures in different ways, and to write user interfaces that behave consistently on different platforms when I/O failures occur; and

• The new filesystem interface will work more consistently across platforms, will make it easier to write programs that gracefully handle the failure of filesystem operations, will provide more efficient access to a larger set of file attributes, will allow developers of sophisticated applications to take advantage of platform-specific features when absolutely necessary, and will allow support for non-native filesystems, such as network filesystems, to be "plugged in" to the platform.

2.4 Why aren't these needs met by existing specifications?

Some of the above needs can be met by using existing APIs together with a significant amount of custom code. It is possible, for example, to write a class that implements the DataInput interface and runs about eight times faster than the built-in DataInputStream class. The Java community would be better served if the Java platform made this sort of work unnecessary.

Some of the above needs can be met by using existing APIs in fragile, implementation-specific ways. To recover from specific types of I/O errors, for example, developers sometimes write code that dissects the message strings of generic IOException objects. This technique may work with a particular implementation of Java on a particular operating system, but it is not very portable. A different implementation on a different operating system may, in a given situation, throw an IOException object with a completely different message string.

Finally, most of the above needs cannot be met simply because the required functionality is not provided by the current I/O APIs.

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

The scalable I/O API, the binary I/O API, and the new filesystem interface will rely heavily upon services provided by the underlying operating system and hardware platform. To implement these components will require writing native code to interface to such services. We hope to keep the amount of native code 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.)

We propose to create one new package, java.nio, with additional subpackages as needed. Platform-specific APIs, if any, will be placed in com.sun.java.nio and subpackages thereof. These names are subject to change as the work progresses. A few classes and methods may be added to the existing java.io, java.lang, java.net, java.text, and java.util packages as appropriate.

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 I/O APIs will be heavily influenced 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 be defined, but the current security model is more than adequate.

2.9 Are there any internationalization or localization issues?

The proposed character-set converter API will improve the Java platform's suitability for developing internationalized applications and will fulfill a long-standing need of the internationalization community.

The proposed parsing and formatting APIs present internationalization issues that have not yet been fully investigated.

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 are not proposing to deprecate the current java.io APIs, but we do hope that most developers will eventually migrate to the new APIs.

The proposed parsing and formatting APIs will duplicate some of the functionality already provided by the java.text package. This duplication is acceptable because the new APIs are intended to be efficient and easy to use for common, simple situations, while the java.text APIs were designed for maximal generality and flexibility.

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.

Sun has been working on an internal draft specification for several months now. This specification is not yet publicly available.

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

The draft specification can serve as a starting point for the work of the Expert Group. We expect to complete the draft by the time the Expert Group is formed.