Over a million developers have joined DZone.

Introducing OWNER, a Tiny Framework for Java Properties Files.

DZone's Guide to

Introducing OWNER, a Tiny Framework for Java Properties Files.

· Java Zone ·
Free Resource

Take 60 minutes to understand the Power of the Actor Model with "Designing Reactive Systems: The Role Of Actors In Distributed Architecture". Brought to you in partnership with Lightbend.

I never liked to create “wrapper” classes for properties files. Do you know… those classes like:

public class MyAppConfig {
    private static Properties p = ...;

    public static String serverName() {
        return p.getProperty("server.name");

    public static int serverPort() {
        return Integer.parseInt(p.getProperty("server.port"));


There’s nothing really bad about those classes. Only that they don’t do actually anything useful; plus, you need to keep things in sync with the properties file associated.

So, I always preferred to directly use Properties.getProperty() and pass a config properties to objects:

public class MyBusinessClass {
    private final Properties conf;
    public MyBusinessClass(..., Properties conf) {
        this.conf = conf;

    public void doSomething() {
        String serverName = conf.getProperty("server.name");
        int serverPort = Integer.parseInt(conf.getProperty("server.port"));

99% of the times, you need a configuration setting in a single point. So that’s good enough, and I don’t have to write (and keep in sync) a class that I can spare.

But… what about this?

public interface MyAppConfig extends Config {

    String serverName();

    int serverPort();

Add to this, a smart -annotation based- configuration loading:

@Sources({"file:~/.myapp.config", "file:/etc/myapp.config", "classpath:foo/bar/baz.properties"})
public interface MyAppConfig extends Config {

And a simple instantiation:

MyAppConfig conf = ConfigFactory.create(MyAppConfig.class);

And you have OWNER. A little configuration framework based on Java properties.

BSD license.
Credits to Google GWT, that does similar things with i18n.


Learn how the Actor model provides a simple but powerful way to design and implement reactive applications that can distribute work across clusters of cores and servers. Brought to you in partnership with Lightbend.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}