JSRs: Java Specification Requests
JSR 10: Preferences API Specification
Section 1: Identification
This JSR is submitted jointly by Sun Microsystems, Inc. (Sun) and the International Business Machines Corporation (IBM).
Section 2: Request
Target Java Platforms - Desktop, Enterprise, Personal, Embedded.
Need that the work addresses - The proposed specification adds a simple API for managing user preference data and configuration data. Applications require preference and configuration data to adapt to different users, environments and needs. Applications need a way to store, retrieve, and modify this data.
Why the need isn't met by existing specifications - Currently, developers have two choices: either they make do without preference and configuration data (leading to reduced functionality), or they manage it in an ad hoc fashion. Often (though not always) preference and configuration data is stored in Properties Files, accessed through the java.util.Properties API. There are no standards as to where these files should reside on disk, or what they should be called. This makes it extremely difficult to backup a user's preference data, or transfer it from one machine to another. As the number of applications increases, the possibility of file name conflicts looms large. Further, this mechanism is of no help on platforms that lack a local disk, or where it is desirable that the data be stored in an external data store (such as an enterprise-wide LDAP directory service).
Less frequently, developers store user preference and configuration data in a directory service, accessed through the Java Naming and Directory Interface (JNDI) API. Unlike Properties, JNDI allows the use of arbitrary data stores (back-end neutrality). While JNDI is extremely powerful, it is also rather large, consisting of 5 packages and 83 classes. Further, JNDI does not provide any policy as to where in the directory name space the preference data should be stored, or in which name space.
In sum, neither Properties nor JNDI provide a simple, ubiquitous, back-end neutral preferences management facility. This JSR proposes such a facility, combining the simplicity of Properties with the back-end neutrality of JNDI. Further, it provides sufficient built-in policy to prevent name clashes, foster consistency, and encourage robustness in the face of inaccessibility of the backing data store.
Specification to be developed: Scope and Content - The specification will consist of the JavaDoc for a small package consisting of a single Preferences class and a few helper classes. The API will provide a simple mechanism for applications to store, retrieve, and modify user preference data, independent of the backing store.
Underlying technologies - Possible implementations of the API include: JNDI, flat files, OS-specific registries, and SQL databases. It is up to each JRE vendor to pick an appropriate default mechanism (or mechanisms) to ship with their JRE.
Proposed package name -
Possible platform dependencies - Each JRE implementor would have to choose an appropriate "backing store" for the preferences data, and write a Preferences implementation for that backing store if one were not already available. Some implementations (such as an OS-specific registry) will require native code.
Security implications - In some environments, it will be desirable to control access to preference data. The Preferences API will not mandate such access control, or specify it in detail, but it will be compatible with such access control.
Internationalization and localization dependencies - None.
Risk assessment - Providing this API will cause a certain amount of confusion among developers who have grown used to coping with Properties Files or the direct use of JNDI. The level of chaos may temporarily increase as preference data migrates from Properties files to Preferences. Failing to provide this API may hinder adoption of the platform (as competing platforms do provide such a mechanism, and it is widely used). Further, failing to provide this API may increase the profusion of ad hoc solutions, leading to a permanent increase in the level of chaos and difficulty of administration.
Existing specifications that might be rendered obsolete or deprecated by
this work - This API would further reduce the applicability of
Existing specifications that might need revisions as a result of this work - Many existing facilities (for example, The Java Cryptography Extension) store preference or configuration data in properties files. Over time, these facilites should migrate their data into the Preferences mechanism.
Section 3: Contributions
Sun and IBM, in collaboration with the Network Computer Management Group (NCMG) have developed a simple Preferences API. It is hoped that this API will form the basis for the specification.
Section 4: Frequently Asked Questions (FAQ) about the proposed Preferences API
Here are a few frequently asked questions about the proposed Preferences API that reviewers might find useful.