Storage of Application Preferences Core Java

  • Enumeration<Applet>getApplets()
    returns an enumeration of all the applets in the same context, that is, the same web page.
  • Applet getApplet(String name)
    returns the applet in the current context with the given name; returns null if none exists. Only the current web page is searched.
  • void showDocument(URL url)
  • void showDocument(URL url, String target)
    shows a new web page in a frame in the browser. In the first form, the new page displaces the current page. The second form uses the target parameter to identify the target frame.

Storage of Application Preferences

Users of your applications will usually expect that their preferences and customizations are saved, and later restored when the application starts again. First, we cover the simple approach for storing configuration information in property files that Java applications have traditionally taken. We then turn to the powerful preferences mechanism that was introduced in Java SE 1.4.

Property Maps

A property map is a data structure that stores key /value pairs. Property maps are often used for storing configuration information. Property maps have three particular characteristics:

  • The keys and values are strings.
  • The set can easily be saved to a file and loaded from a file.
  • There is a secondary table for default values.
    The Java class that implements a property map is called Properties.

Property maps are useful in specifying configuration options for programs. For example:

Use the store method to save this list of properties to a file. Here, we just save the property map in the file The second argument is a comment that is included in the file.

It is customary to store program properties in a subdirectory of the user’s home directory. The directory name is often chosen to start with a dot—on a UNIX system, this convention indicates a system directory that is hidden from the user. Our sample program follows this convention.

To find the user’s home directory, you can call the System .get Properties method, which, as it happens, also uses a Properties object to describe the system information. The home directory has the key "user.home". There is also a convenience method to read a single key:

It is a good idea to provide defaults for our program properties, in case a user edits the file by hand. The Properties class has two mechanisms for providing defaults. First, whenever you look up the value of a string, you can specify a default that should be used automatically when the key is not present.

If there is a "title" property in the property map, title is set to that string. Otherwise,

title is set to "Default title".

If you find it too tedious to specify the default in every call to get Property, then you can pack all the defaults into a secondary property map and supply that map in the constructor of your primary property map.

Yes, you can even specify defaults to defaults if you give another property map parameter to the defaultSettingsconstructor, but it is not something one would normally do.

The program remembers the frame position, size, and title. You can also manually edit the file .core java /program .properties in your home directory to change the program’s appearance to the way you want

NOTE: Properties are simple tables without a hierarchical structure. It is common to introduce a fake hierarchy with key names such as window .main .color, window .main .title, and so on. But the Properties class has no methods that help organize such a hierarchy. If you store complex configuration information, you should use the Preferences class instead —see the next section.

java.util.Properties isting

  • Properties()
    creates an empty property map.
  • Properties(Properties defaults)
    creates an empty property map with a set of defaults.
  • String getProperty(String key)
    gets a property map. Returns the string associated with the key, or the string associated with the key in the default table if it wasn’t present in the table, or nullif the key wasn’t present in the default table either.
  • String getProperty(String key, String defaultValue)
    gets a property with a default value if the key is not found. Returns the string associated with the key, or the default string if it wasn’t present in the table.
  • void load(InputStream in) throws IOException
    loads a property map from an input stream.
  • void store(OutputStream out, String header) 1.2
    saves a property map to an output stream.
  • Properties getProperties()
    retrieves all system properties. The application must have permission to retrieve all properties or a security exception is thrown.


  • String getProperty(String key)
    retrieves the system property with the given key name. The application must have permission to retrieve the property or a security exception is thrown. The following properties can always be retrieved:

NOTE: You can find the names of the freely accessible system properties in the file security/ java.policyin the directory of the Java runtime.

The Preferences API

As you have seen, the Properties class makes it simple to load and save configuration information. However, using property files has these disadvantages:

  • Configuration files cannot always be stored in the user’s home directory. Some operating systems (such as Windows 9x) have no concept of a home directory.
  • There is no standard convention for naming configuration files, increasing the likelihood of name clashes as users install multiple Java applications.

Some operating systems have a central repository for configuration information. The best -known example is the registry in Microsoft Windows. The Preferences class of Java SE 1.4 provides such a central repository in a platform -independent manner. In Windows, the Preferences class uses the registry for storage; on Linux, the information is stored in the local file system instead. Of course, the repository implementation is transparent to the programmer using the Preferences class.

The Preferences repository has a tree structure, with node path names such as /com /mycompany /myapp. As with package names, name clashes are avoided as long as programmers start the paths with reversed domain names. In fact, the designers of the API suggestthat the configuration node paths match the package names in your program.

Each node in the repository has a separate table of key /value pairs that you can use to store numbers, strings, or byte arrays. No provision is made for storing serializableobjects. The API designers felt that the serialization format is too fragile for long-term storage. Of course, if you disagree, you can save serialized objects in byte arrays.

For additional flexibility, there are multiple parallel trees. Each program user has one tree, and an additional tree, called the system tree, is available for settings that are common to all users. The Preferences class uses the operating system notion of the “current user” for accessing the appropriate user tree.

To access a node in the tree, start with the user or system root:

Then access the node. You can simply provide a node path name:

A convenient shortcut gets a node whose path name equals the package name of a class.

Simply take an object of that class and call

Note that you must specify a default value when reading the information, in case the repository data is not available. Defaults are required for several reasons. The data might be missing because the user never specified a preference. Certain resource-constrained platforms might not have a repository, and mobile devices might be temporarily disconnected from the repository.

Conversely, you can write data to the repository with put methods such as put(String key, String value)

putInt(String key, int value) and so on. You can enumerate all keys stored in a node with the method String[] keys

But there is currently no way to find out the type of the value of a particular key. Central repositories such as the Windows registry traditionally suffer from two problems:

  • They turn into a “dumping ground,” filled with obsolete information.
  • Configuration data gets entangled into the repository, making it difficult to move preferences to a new platform.

The Preferences class has a solution for the second problem. You can export the preferences of a subtree (or, less commonly, a single node) by calling the methods

The data are saved in XML format. You can import them into another repository by

Calling void importPreferences(InputStream in) Here is a sample file:

If your program uses preferences, you should give your users the opportunity of exporting and importing them, so they can easily migrate their settings from one computer to another. The program simply saves the position, size, and title of the main window. Try resizing the window, then exit and restart the application. The window will be just like you left it when you exited.


  • Preferences userRoot()
    returns the root preferences node of the user of the calling program.
  • Preferences systemRoot()
    returns the systemwide root preferences node.
  • Preferences node(String path)
    returns a node that can be reached from the current node by the given path. If path is absolute (that is, starts with a /), then the node is located starting from the rootof the tree containing this preference node. If there isn’t a node with the givenpath, it is created.
  • Preferences userNodeForPackage(Class cl)
  • Preferences systemNodeForPackage(Class cl)
    returns a node in the current user’s tree or the system tree whose absolute node path corresponds to the package name of the class cl.
  • String[] keys()
    returns all keys belonging to this node.
  • String get(String key, String defval)
  • intgetInt(String key, intdefval)
  • long getLong(String key, long defval)
  • float getFloat(String key, float defval)
  • double getDouble(String key, double defval)
  • booleangetBoolean(String key, booleandefval)
  • byte[] getByteArray(String key, byte[] defval)
    returns the value associated with the given key, or the supplied default value if no value is associated with the key, or the associated value is not of the correct type, or the preferences store is unavailable.
  • void put(String key, String value)
  • void putInt(String key, int value)
  • void putLong(String key, long value)
  • void putFloat(String key, float value)
  • void putDouble(String key, double value)
  • void putBoolean(String key, boolean value)
  • void putByteArray(String key, byte[] value)
    stores a key/value pair with this node.
  • void exportSubtree(OutputStream out)
    writes the preferences of this node and its children to the specified stream.
  • void exportNode(OutputStream out)
    writes the preferences of this node (but not its children) to the specified stream.
  • void importPreferences(InputStream in)
    imports the preferences contained in the specified stream.

This concludes our discussion of Java software deployment. In the next chapter, you learn how to use exceptions to tell your programs what to do when problems arise at runtime. We also give you tips and techniques for testing and debugging so that not too many things will go wrong when your programs run.

Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Core Java Topics