Best approach storing and accessing Java application data

Question

I'm in the middle of a massive refactoring project, the code has a 5000 line main class which was injected into everything, stored everything and had all of the common code.

I'm no expert on analysis and design but I've separated out things to the best of my ability and I'm about 80% through refactoring the classes that depend on the main class to use the new classes I've created.

There are some types of data which are initialised when the application starts and accessed by pretty much everything throughout the life of the application. For instance there is a Config class which holds hundreds of parameters.

The approach I've taken is to create several singletons the two most central are GUIData and ClientData. GUIData contains a reference to the mainframe of the application and clientdata maintains references to the config and other similar classes.

This allows me to call ClientData.getInstance().getConfig().getParam("param") from anywhere in the code but I don't feel like this is the best approach.

I considered individual static classes instead of these data singletons which contain instances of the classes but some of the classes do need constructors.

I've been googling on and off for a week trying to find a better way to do this but somehow I always end up on threads talking about database caching

Answer 1

Immutable (configuration) instances provide "thread-safe application-wide data access". Typesafe's config (as suggested in a comment by Brian Kent) does exactly that. Note that this does not involve static classes or singletons. Static classes and singletons may serve your purposes now, but they could prove bothersome in the future. They can be handy ofcourse, but try limiting their use.

Initialization will have to be done after reading and parsing the configuration data. It is typically done at application startup, before other processing threads are started. The initialization will have to validate the configuration data as much as possible in order to fail fast and terminate the program if the configuration data is no good.

Having a lot of configuration data bundled together can create "hidden lines of communication". E.g. you update one value and the application fails because it required updates to other values as well. It's perfectly fine to put all configuration data in one file and load it from there, but your application (with hundreds of configuration options) should divide the configuration data in sets that are used by different parts of your application. This improves isolation, helps unit-testing and makes it possible to change the application in the future without getting too many nasty surprises.

There are two ways to use a set of configuration data:

1. from within an object call a singleton Settings.getInstance().getConfigForThisModule().
2. provide each object that uses configuration data with the configuration data via the constructor or via setConfig(ConfigForThisModule config).

The first approach depends on a convention not to call Settings.getInstance().getConfigForACompletelyUnrelatedModule() which could be a weakness. The second approach is more in line with "dependency injection" and could be more future proof. You could mix both approaches while you are refactoring, just make sure to be consistent (e.g. only use the singleton approach for configuration data that is used in all parts of the application).

To further improve your design for using the configuration data, keep the following (likely) future functional requirement in mind: when the configuration file is updated, configuration data is reloaded and used in the application. Most logging frameworks manage to support this functional requirement without affecting the performance of multi-threaded applications. Among other things, it requires the following of your application:

• if the new configuation data is no good, the program is not terminated but an error is logged instead and the old configuration data remains in use. Your initialization procedure will need to handle both "load at fresh start" and "reload" scenarios. The main thing to take away from this is that your initialization procedure needs to be re-usable and should not affect other (running) parts of your application (isolation, again).
• long-lived objects may not keep a local copy of configuration data or a reference to an instance of ConfigForThisModule, instead Settings.getInstance()... (or some other method that can return an updated instance) should be called regurarly.
• replacing old configuration with new configuration may not result in errors. Technically, replacing the configuration is as simple as updating an AtomicReference with a new configuration instance returned with Settings.getInstance().... But this is also where the isolation of the configuration data sets are tested: there should be no problem using an old set in one module and a new set in another module at the same.

Configuration data can be seen as a sort of "global state". With that in mind, further design points on what to do and what to avoid (partially blatantly copied to this answer) are discussed in the following two questions:

• Why is Global State so Evil?
• How are globals any different from a database?

Answer 2

you can use the Java Properties class util, basically its a HashTable reference : https://docs.oracle.com/javase/7/docs/api/java/util/Properties.html

you create a file fileName.properties and store your data in key value pairs, for example:

username=your name
port=8080

then you load it into Properties Object and get the data like the following:

Properties prop = new Properties();
load the file...
String userName = prop.getProperty("username")
String port = prop.getProperty("port")// you can parse it to int if needed

what i suggest is to create a property file for each type of configuration like:

1. clientData.properties
2. appConfig.properties

you can follow this simple tutorial http://www.mkyong.com/java/java-properties-file-examples/

Answer 3

If it's just String property values you need, you don't even need a class for that - a global facility exists for you already: System.getProperties()

All you need do is first load the property values on start up:

System.setProperty("myKey", "myValue"); // see below how load properties from a file

Then read it anywhere in your code:

String myValue = System.getProperty("myKey");

or

String myValue = System.getProperty("myKey", "my desired default");

---

If your container doesn't support property loading out of the box, to load properties from an external file that looks like this:

key1=value
key2=some other value
etc...

you can use this code:

Files.lines(Paths.get("path/to/file"))
  .filter(line -> !line.startsWith("#") || !line.contains("=")) // ignore comment/blank
  .map(line -> line.split("=", 2)) // split into key/value
  .forEach(split -> System.setProperty(split[0], split[1])); // load as property

Answer 4

Sorry, the question is a bit vague, are you looking to store the config or the cached objects used by other parts of your program ?

Since you have 100s of params, start with splitting up the config into manageable blocks

1) Split up your configuration parameters into logical blocks that have 1:1 correspondence with a simple properties file -its going to take some time

2) These property files must be externalized so that you can change them at any point in time, make sure that you pass in the base location via a env variable to the program

3) Write a utility class (singleton) that wraps Apache commons configuration to hold your config. (read *.properties from the base location and merge the properties into one configuration object) this must be done before any threads are kicked off.

4) Refer to the configuration param in your code using config.getXXXX() methods

Apache commons config also has ability to reload the config when your properties file changes on the filesystem.

Once this is done, use a DI container like Spring or Guice to cache the configured objects.