It is a truth universally acknowledged that a single program in possession of a good configuration must be in want of a way to easily access it.
—Jane Austen?

Any non-trivial software, at some point, needs a way to allow users to configure it. By far the easiest solution is to use a text file with some convention (.ini, .yaml, .json, .xml, .you name it) and parse it at the start.

Java has had support for properties files since version 1, and it’s probably the easiest way to configure Java programs. The class Properties has the methods load and store to read and write property files. So far so good.

FileOutputStream out = new FileOutputStream("appProperties");
Properties prop = new Properties();
prop.setProperty("port", "1234");
prop.store(output, "comment");
out.close();
. . .
Properties prop = new Properties();
FileInputStream in = new FileInputStream("appProperties");
prop.load(in);
String port = prop.getProperty("port");
in.close();

Where do we keep the configuration in the program?

There are three common solutions:

1. A singleton. Once read, we can keep the Properties object as a singleton and then we are able to read from it anywhere in the code.
2. A higher level object that wraps all the around configuration. Typically, this is called ConfigManager or PropertyManager. Then, we can pass this object to any method that needs to read the configuration.
3. We parse the config and make specific value objects immutable to keep them logically organized.

The singleton solution is the easiest to implement, but it’s also the most fragile: If we want to change a configuration, we have to check all our code, since it can be called everywhere. Then, for any class that needs them, we need to mock the singleton. Finally, there could be some logic to access configuration, and we need to remember to use same logic everywhere.

The manager solution has the advantage of keeping all the logic together, and it is usually easier to mock, since we own the interface. The problem is that we need to write more code, again and again.

The value objects are the cleanest solution, but they require a lot of boilerplate code to read the property file and set the value object. Or do they?

Enter Owner.

Disclaimer and full disclosure: The author of Owner is a dear friend of mine and one of the best programmers I have ever worked with.

As you may have guessed at this point, Owner is a library that loads value objects from your configuration files, or creates the config files from your objects.

Now I have a small project on GitHub that exposes a rest API to do simple mortgage-like calculations. I'm using it as an exercise and starting point for a more complicated proof of concept.

Now I want a configuration file to specify the port to listen and the list of UserAccounts.

The first step is straightforward enough: Just add the dependency in Gradle (or Maven). Note that if you are using a Java version older than Java 8 you the need the owner package, not owner-java8.

dependencies {
    compile 'com.sparkjava:spark-core:2.6.0'
    testCompile "junit:junit:4.12"
    compile 'org.slf4j:slf4j-simple:1.7.21'
    compile 'org.aeonbits.owner:owner-java8:1.0.9'
}

Step two: create an interface with all the properties you need. You can specify the default values using annotations.

Note that all properties come properly typed. While using a standard Properties class, all properties are Strings. For List properties, you just have to specify values separated by commas.

By default, Owner looks for the config file inside the resources, with the same package/file of the interface. I prefer an external text file, so I just have to specify the file location with another annotation. Note that I can even specify more than one location and the algorithm used to merge them!

Step three: You just have to call ConfigFactory.create and everything just works!

Owner can do much more than this: You can specify property separators, hot-reload, remote properties (Zookeeper), mutable values, etc. Just read the documentation.

Have fun!