Here are a few frequently asked questions about the proposed Preferences API that provide a rudimentary design rationale for the API:
It is intended to replace most common uses of Properties,
rectifying many of its deficiencies, while retaining its light weight. When
using Properties, the programmer must explicitly specify a pathname
for each properties file, but there is no standard location or naming
convention. Properties files are "brittle", as they are hand-editable but
easily corrupted by careless editing. Support for non-string data types in
properties is non-existent. Properties cannot easily be used with a
persistence mechanism other than the file system. In sum, the
Properties facility does not scale.
Like JNDI, it API provides back-end neutral access to persistent
key-value data. JNDI, however, is far more powerful, and correspondingly
heavyweight. JNDI is appropriate for enterprise applications that need its
power. This API is intended as a simple, ubiquitous, back-end neutral
preferences-management facility, enabling any Java application to
easily tailor its behavior to user preferences and maintain small amounts of
state from run to run.
getmethods require the caller to pass in a default?
This forces the authors of applications to provide reasonable
default values, so that applications have a reasonable shot at running
even if the repository is unavailable.
Only the methods whose semantics absolutely require the ability to
communicate with the backing store throw this exception. Typical
applications will have no need to call these methods. As long as these
methods are avoided, applications will be able to run even if the backing
store is unavailable, which was an explicit design goal.
While the the API does provide rudimentary persistent data storage, it is
not intended as a substitute for a database. It is critical that it be
possible to implement this API atop standard preference/configuration
repositories, most of which do not provide database-like
guarantees and functionality. Such repositories have proven adequate for the
purposes for which this API is intended.
In the Java programming universe, case-sensitive String keys are
ubiquitous. In particular, they are provided by the Properties class,
which this API is intended to replace. It is not uncommon for people to use
Properties in a fashion that demands case-sensitivity. For example,
Java package names (which are case-sensitive) are sometimes used as keys. It
is recognized that this design decision complicates the life of the systems
programmer who implements Preferences atop a backing store
with case-insensitive keys, but this is considered an acceptable price to
pay, as far more programmers will use the Preferences API than will
This API is designed for a very particular purpose, and is optimized
for that purpose. In the absence of generic types (see
JSR-14), the API would be less convenient for typical users, and would
lack compile-time type safety, if were forced to conform to the Map
API. Further, it is not anticipated that interoperability with other
Map implementations will be required (though it would be
straightforward to implement an adapter class if this assumption turned out to
be wrong). The Preferences API is, by design, so similar to
Map that programmers familiar with the latter should have no
difficulties using the former.
It is highly desirable that both of these methods be executable even if the
backing store is unavailable. This would not be possible if they were
required to return the old value. Further, it would have negative
performance impact if the API were implemented atop some common back-end
This functionality is required in enterprise settings for scalable,
cost-effective administration of preferences across the enterprise, but would
be overkill in a self-administered single-user setting.
Serialized objects are somewhat fragile: if the version of the
program that reads such a property differs from the version that wrote
it, the object may not deserialize properly (or at all). It is not
impossible to store a serialized objects using this API, but
we do not encouraged it, and have not provided a convenience
Preferencesan abstract class rather than an interface?
It was felt that the ability to add new methods in an upward compatible
fashion outweighed the disadvantage that Preferences can not be used
as a "mixin (that is to say, arbitrary classes cannot also be made to serve as
Preferences objects. Also, this obviates the need for a separate
class for the static methods. (Interfaces cannot contain static methods.)