JSRs: Java Specification Requests
JSR 51: New I/O APIs for the JavaTM Platform
Section 1. Identification
Submitting Participant: Sun Microsystems, Inc.
Name of Contact Person: Mark Reinhold
E-Mail Address: firstname.lastname@example.org
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:
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.
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.