Using Program Parameters in Java Part-3

Databases

Why not store parameters in a database? If your application is already using a database, you might consider defining a special table for this purpose. To hold key-value pairs you need two columns of type char: “key” and “value”. If you want a really flexible solution you should consider making a small (Swing or web?) application that can be used to insert and update the data in this table.

Where property files are fine for utility type and stand-alone programs, a database could be a better solution for applications with many users, for example web applications. To avoid access to the database every time there’s a need for a parameter value, you could load the parameters on system startup, and then keep them in a Properties or HashMap object held by a singleton. When (if) you update a parameter value, you’d update the database and also the HashMap. To do this properly you must synchronize access to the HashMap.

Hiding the implementation

As you can see there are many possibilities for storing parameters. When you choose one of them for your application, you might want to start with a simple solution, where you get the parameters from a property file, for example. Later you might want to read the parameters from a database, so it’d be nice if you could hide the implementation details of how you actually get the parameters. Let’s define an interface as simply as possible. What we need is a method with this signature:

If you put the method in a singleton class (you only need one instance since there is no state to preserve) you may define the method to be static:

To get your parameters use a method call like this:

No implementation is visible, right? The way to code the singleton could be like this, if we chose to use a property file:

I’ve also thrown in some simple error handling using Log4J because we all know that this can not be left out in a professional application!

When the getValue method is used the first time the property file will be read and the Properties object “p” will be filled with the key- value pairs from the file. Since the constructor is private the file will only be read once. Here are a few lines to test the class:

We’ve hardcoded the name of the property file in the class, which is not very flexible. We’ll therefore add another method, initialize, that allows us to enter the filename. To handle this we introduce two variables currentFile and nextFile, and change a few lines of the code:

Note, that to avoid creating more than one instance of Parameter1 we always get the instance by calling the synchronized method getInstance.

Before we use the getValue method we’ll have to make a call to initialize:

We can improve the code even more. If we want to facilitate unit testing of the application using the parameter values, it’d be nice to be able to stick in key-value pairs without actually needing a file:

Here’s how we may set our own key-value pairs: