The Preferences API in Java 2SE 1.4 (Merlin)
Pages: 1, 2
Where Is The Data?
The details about where the data is actually stored may vary from platform to
platform. Each of the static methods in the Preferences class that
returns a Preferences object are relying on a factory that creates
the Preferences object. This factory is some concrete
implementation of the java.util.prefs.PreferencesFactory interface.
The name of the concrete factory class to use is specified by the
java.util.prefs.PreferencesFactory system property. The
documentation explicitly states that this is NOT part of the
specification and is subject to change in future releases. On Linux, the value
of this system property is
java.util.prefs.FileSystemPreferencesFactory so the Preferences API
will use an instance of that class whenever an instance of
Preferences is requested via one of the static methods in the
Preferences class. This particular implementation stores all of the
preference data in files on the file system. On Windows 2000, the value of this
system property is java.util.prefs.WindowsPreferencesFactory. This
implementation stores all of the preference data in the Windows Registry.
Specifically, system preferences are stored under
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs and user preferences are
stored under HKEY_CURRENT_USER\Software\JavaSoft\Prefs.
This screen shot shows the data stored by the
PreferenceTestFrame application shown above. Of course the
application code makes no references to the Windows Registry. The application is
written to the standard Preferences API.
There are facilities built into the Preferences API to allow preference data to be exported and imported to and from an eXtensible Markup Language (XML) file.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE preferences SYSTEM 'http://java.sun.com/dtd/preferences.dtd'>
<preferences EXTERNAL_XML_VERSION="1.0">
<root type="user">
<map />
<node name="com">
<map />
<node name="ociweb">
<map />
<node name="preferencestest">
<map>
<entry key="TEST_WINDOW_WIDTH" value="256" />
<entry key="TEST_WINDOW_HEIGHT" value="314" />
<entry key="TEST_WINDOW_X" value="540" />
<entry key="TEST_WINDOW_Y" value="63" />
</map>
</node>
</node>
</node>
</root>
</preferences>
This XML was created by calling the exportSubtree(OutputStream)
method on an instance of Preferences that was associated with the
root of the user preference tree. These are the same preferences reflected in
the Windows Registry screenshot shown above. The exportSubTree(OutputStream) method exports any particular node and
all of its sub-nodes in the tree. The exportNode(OutputStream)
method exports a particular node and does not include any of its sub-nodes. Each
of those methods are instance methods as they operate on a particular node in
the tree.
|
Related Reading
|
The static method importPreferences(InputStream) in the
Preferences class imports preferences from an XML source and adds
those preferences to the appropriate preference tree. If any of the nodes
represented in the XML do not exist in the preference tree, they are created.
Comparing With Property Files
Without the Preferences API, many applications have taken advantage of Java
Property files for storing simple data like that accounted for by the
Preferences API. In comparison to using Property files, the Preferences API
provides a more robust mechanism for organizing the data without introducing
complexity. For example, Property files do not provide any easy way to group
data hierarchically. This flexibility is built into the Preferences model.
Property files are dependent on a file system, which may not exist on every
platform with a Java VM, for example a cellular telephone. There is nothing
about the Preferences API that depends on a file system. For platforms without a
file system, an implementation of java.util.prefs.PreferencesFactory could be developed that stores the data using whatever mechanisms are appropriate for that platform.
Summary
The Preferences API provides a nice interface for storing application preferences in a platform independent way. While the details about the storage of the data vary from platform to platform, the application code is as portable as any other Java code.
This article has been written as of J2SE v1.4 beta 2. Keep an eye out for changes that may be made to the API before the final release of v1.4.
Jeff Brown is a Senior Software Engineer, Object Computing, Inc. (OCI)
Return to ONJava.com.
Jeff Brown is a Senior Software Engineer, Object Computing, Inc. (OCI)
Return to ONJava.com.
