This interface allows applications to store and retrieve user and system preference data. This data is stored persistently in an implementation-dependent backing store. Typical implementations include flat files, OS-specific registries, directory servers and SQL databases.
For each bundle, there is a separate tree of nodes for each user, and one for system preferences. The precise description of "user" and "system" will vary from one bundle to another. Typical information stored in the user preference tree might include font choice, and color choice for a bundle which interacts with the user via a servlet. Typical information stored in the system preference tree might include installation data, or things like high score information for a game program.
Nodes in a preference tree are named in a similar fashion to directories in a hierarchical file system. Every node in a preference tree has a node name (which is not necessarily unique), a unique absolute path name , and a path name relative to each ancestor including itself.
The root node has a node name of the empty {@code String} object (""). Everyother node has an arbitrary node name, specified at the time it is created. The only restrictions on this name are that it cannot be the empty string, and it cannot contain the slash character ('/').
The root node has an absolute path name of {@code "/"}. Children of the root node have absolute path names of {@code "/" + } <node name> .All other nodes have absolute path names of <parent's absolute path name> {@code + "/" + } <node name> . Note that allabsolute path names begin with the slash character.
A node n 's path name relative to its ancestor a is simply the string that must be appended to a 's absolute path name in order to form n 's absolute path name, with the initial slash character (if present) removed. Note that:
Note finally that:
Each {@code Preference} node has zero or more properties associated with it,where a property consists of a name and a value. The bundle writer is free to choose any appropriate names for properties. Their values can be of type {@code String}, {@code long}, {@code int}, {@code boolean}, {@code byte[]}, {@code float}, or {@code double} but they can always be accessed as if theywere {@code String} objects.
All node name and property name comparisons are case-sensitive.
All of the methods that modify preference data are permitted to operate asynchronously; they may return immediately, and changes will eventually propagate to the persistent backing store, with an implementation-dependent delay. The {@code flush} method may be used to synchronously force updates tothe backing store.
Implementations must automatically attempt to flush to the backing store any pending updates for a bundle's preferences when the bundle is stopped or otherwise ungets the Preferences Service.
The methods in this class may be invoked concurrently by multiple threads in a single Java Virtual Machine (JVM) without the need for external synchronization, and the results will be equivalent to some serial execution. If this class is used concurrently by multiple JVMs that store their preference data in the same backing store, the data store will not be corrupted, but no other guarantees are made concerning the consistency of the preference data. @noimplement @author $Id: faefeec3c75c0a45324035226f71728f69358cd4 $
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |