Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Sir, what is your preference?

Manage your application's preferences with J2SE 1.4's new Preferences API

By Ray Djajadinata, JavaWorld.com, 08/31/01

  • Print
  • Feedback
.
Almost all but the smallest applications have preferences -- a set of values that affect how the application behaves at runtime. Preferences examples range from configuring an MP3 player to sport a skin of your choice, to setting a 3D shooter game's to varying screen resolutions. Now, of course you want the values to be there next time you run the application, so usually they're made persistent, be it in a file, database, or some other storage mechanism.

As an application developer, how and where you put the preferences vary depending on your application, the platform it runs on, and the programming language. If your application will run only on Windows, then Registry is the place to put the preferences. Developers writing applications written in portable C/C++, on the other hand, usually put their preferences in files. Bigger, server-side applications might store them in a database (although usually something needs to be stored in a file -- the connection string to the database, for example).

Therefore, when designing your application, you'll always face the same preference management questions: Where do we store them? How? Is maintaining them easy enough? Can we easily move them to another platform when necessary? If Java is your programming language, you can follow several approaches in answering these questions. I'll compare the traditional approaches, then discuss in detail the latest option -- J2SE (Java 2, Standard Edition) 1.4's new Preferences API. Enjoy!

The old, simple, and unscalable approach

Ahhh -- good old Properties. It has been around since Java's beginning, JDK 1.0 to be exact. It's easy to use: just put the preferences into the Properties object and store them in a file. Later, when you need to get them back, load it from the file, and voila, you have a Properties object containing the values you previously stored in the file. It's as simple as that. What could possibly be wrong with this approach?

The problems with Properties

For simple applications with just a few preferences, java.util.Properties works just fine. However, as the application grows in size, with the Properties API you can develop problems such as:

  • Numerous property files, each assigned to a part of the application (usually, but not always, a package), forcing you to hardcode a gaggle of file names -- or even their paths -- inside your code
  • Several large property files, which force you to prevent name collisions and to track numerous different preferences


To solve the second problem, you'd typically create your own hierarchy out of the flat namespace. That is, you'd create names like:

  • myapp.payment.SSLPort=10256
  • myapp.payment.SETPort=10257
  • myapp.admin.listenPort=10258


Of course, the Properties API possesses no awareness of this hierarchy, so you'd have to add your own code on top of it. However, this approach also proves unsafe: if someone hand-edits the file and replaces a period with a comma in one of the names above, who knows what will happen to your application?

In other words, managing and maintaining preferences using the Properties API can quickly become a nightmare -- it simply doesn't scale! Besides, using the Properties API this way won't work with a platform without a local disk. Now let's take a look at another approach that solves most of these problems.

  • Print
  • Feedback

Resources