Name: ab88733 Date: 11/01/99



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.

This API is being developed under the Java Community Process as JSR-010.