Best practices for loading Properties

Question

I have several classes that need to load some properties files, and I was wondering what are the best practices to accomplish this. I thought of two basic approaches:

• Hardcode the properties file name in each class, and then use the Properties class to load from a FileInputStream, which can be problematic if someone decides to change the name of the properties file, as it is hardcoded in the code.

  public class A {
      public A() {
          Properties p = new Properties().load(
                  new FileInputStream("properties/Aconfig.properties"));
          String value = p.getProperty("key", "");
      }        
  }
  

• Create a method that, given a class name, loads a properties file that has the same name as the class. Though this approach doesn't require to hardcode the properties file name, it does require that we follow some convention in naming the files, which can cause confusion.

  public class A {
      public A() {
          Properties p = PropertiesHelper.loadFromClassName(A.class.getName());
          // here, we **assume** that there is a A.properties file in the classpath.
      }
  }
  

However, there may be many other more elegant approaches, and that's why I posed these questions: i) What are the best practices for loading properties files in Java?; ii) Do you use any helper class that takes care of the job?; iii) Where (in the code) do you typically load the properties file?

Also, is it OK for a class to "auto-load" its properties? Or should I pass the arguments that I need to the constructor ? The problem of passing the arguments, is that there are way too many for some classes (~20, which represent parameters in a statistical model).

Answer 1

In the past, I have loaded properties through a system property - the file name is passed in through the system property, and I load up that file. There is a default name that we use if the system property is not set. If the file does not exist, then you need to decide what to do there.

The nice thing about this is there is a standard, but they can override it's location/name using a command line argument.

Just my 2 cents though.

Answer 2

Have several places for a properties files and load them (one after another) into a single Properties object. This scheme allow a mapping to have a default value that can then be overridden at several points.

Answer 3

The file names can easily be passed in the command line for the app. This can be done either as an arg to the main method (after the main class name) or as a property (as aperkins is alluding, i believe) using the -D flag.

Answer 4

The best practice would be to use some kind of dependency injection container - for example Spring Framework or Google Guice.

It solves all kinds of problems - you don't tie your class to particular property file name, you don't have to worry about loading said properties within that class and handle possible exceptions, and you don't have to pass 30 property file names as command line arguments (or system properties).

It also helps with many, many other things in addition to property loading :-) - try it, and you'll wonder how you ever lived without.

Update: Incidentally, your other question is also one of those things that Spring would take care of.

Update #2: I just realized I've already tried to push Spring on you :-) At the risk of repeating myself, Spring would really help with abstraction here. Depending on what you store in your property files you may not need them at all (if they deal with configuration) or you will get a very nice API for dealing with them (if they're resource bundles or something similar) .

Answer 5

I would suggest avoiding using File and filesystem related paths. It is usually better to use classpath paths (hmm, no pun intended...) because: - it makes your code testable by segregating classloaders between runtime and test time, something which is routinely done by any decent build system - it makes your code location independent and allows you to ignore OS issues - it makes your code work the same as a standalone app or within a container (lightweight, servlet, app server, whatever...)

You can have a look at the PropertyResourceBundle which has the nice additional feature that is Locale-aware, so you could define different properties with different Locale settings. Note that Locale can be abused to provide parameterization independently of l10n or i18n issues, eg. I used on a project a "windows" and a "linux" locale, because you can construct your own Locale instance and pass it to the loader.

Or you can just construct the path yourself...

Or you can load your Properties from an input stream:

      Properties prop = Properties.load(getClass().getResourceAsStream("/myprops"));

HTH.