Developer

Store your app's configuration information with Java Properties

Keeping configuration info handy is a common task. Learn to leverage Java's Properties class for this purpose in your own applications.


You won’t be developing long before you’ll find yourself in need of a way to preserve information between executions of your Java app. Databases are popular options for this purpose, but for small amounts of information, using a database can be overkill. Java provides a class specifically designed to make it easy for you to store small amounts of text information in a text file: java.util.Properties. Think of “application properties,” and you’ll understand the rationale for this name.

The Properties class is essentially a strongly typed wrapper for a Hashtable that allows for writing the contents of the Hashtable to a disk file and retrieving it later. A Hashtable, if you’re wondering, is a collection that organizes its contents based on a string key you associate with each value you add to the collection. That should give you a clue about how information is organized by a Properties instance: multiple sets of key and value pairs.

The disk file is divided into a number of sections, one for each set of properties you persist to the file. Each section has a time stamp representing the last time that section was updated and contains a set of key and value pairs, one for each individual property you store there. This structure will be familiar to you if you’ve ever seen a Windows-style INI file.

Properties in a nutshell
Enough preamble. Let’s jump right in and see how Properties works. To store a property in the Properties object, you’ll use the setProperty method, which accepts a key name for the value and the value itself. To retrieve a property, you’ll use getProperty and pass the key for the value you want to retrieve. By way of example, you’d use something like the following code to store and retrieve a property called Builder:
Properties p = new Properties();
p.setProperty(“Builder”, “Some Value”);
String s = p.getProperty(“Builder”);

Remember when I said Properties was a strongly typed Hashtable? Well, you’re limited to string values only when using setProperty and getProperty.

Of course, the above example doesn’t preserve the value for the Builder property across application runs. It would be nice if that’s all it took, but you’ll have to actually handle creating a File object and the necessary input and output streams on your own. Check out Listing A for a quick and dirty sample program showing how to persist a set of properties across executions on Windows. The code should work equally well on other operating systems, as long as you change the file path from “C:/temp” to a path that makes sense on your platform.

Dealing with default values
So what happens if you try to retrieve a property that doesn’t exist in the file? In that case, the getProperty method returns null. You can certainly check for null in your code, but it would be easier and cleaner if you could somehow automatically specify a default value for a property to use if it doesn’t exist in the properties file.

It works out that you can do just that, in two ways:
  • ·        The Properties constructor has an overload that accepts an instance of another Properties object. You can set properties into this object before passing it to the constructor, and those properties will be used as default values for any properties you try to retrieve that have not been previously defined.
  • ·        One overload of the getProperty method accepts a second string parameter that will be returned should the named property not exist.

The example in Listing A illustrates both of these techniques.

The proper use of Properties
I’ll leave you with a few parting tips on using Properties in your applications:
  • ·        Even though the Properties class has put and putAll methods it inherits from Hashtable, and they'll allow you to set property value types other than String, don’t use them. You’ll wind up with an invalid set of properties that you won’t be able to open.
  • ·        Don’t try to store complex pieces of information in a Properties set. Likewise, don’t store large amounts of information there either. You’re best off storing only the simplest of configuration information there and bringing in the data storage “big guns” (databases) in those situations.

 

Editor's Picks