I find that JSON files mapped to my own classes does wonders. A few annotations are usually all that’s needed to tell the JSON libs how to serialize the class. Outside of this you pretty much live in your code for the rest of the time and get all the benefits of it (refactors, compiler checks, code complete etc).

If you require more strict format and validation of the files then I go for XML by first creating an XSD. Then through JAXB generate the classes, from then on it’s the same deal as JSON above. Bit more involved though, only go this route if you require exchanging the data in these files with system that naturally “speak” XML or if you need a strict validation but dont want to spend the time doing it manually.

Yaml can make a pretty good candidate for config. I tried it recently in a python project and I must say it was really nice ! Not sure what the Java yaml work is like though but I would be very surprised if one could not find a good resource to deal with the yaml format.

You may want to consider YAML

The Dropwizard framework in Java uses YAML for its external configuration. This is easier to work with than JSON since there are no braces.

You can use Jackson to unmarshal the YAML into DTOs with the Jackson Data format YAML module.

Here is an example YAML configuration for configuring the SLF4J within Dropwizard:

logging:

  level: WARN

  # Logger-specific levels.
  loggers:

    # Set specific levels
    "com.sun.jersey.api.client": DEBUG
    "com.yammer": INFO
    "org.multibit": DEBUG

  # ...
  # Settings for logging to stdout.
  console:

    # If true, write log statements to stdout.
    enabled: true

    # Do not display log statements below this threshold to stdout.
    threshold: ALL

  # Settings for logging to a file.
  file:

    # If true, write log statements to a file.
    enabled: false

    # Do not write log statements below this threshold to the file.
    threshold: ALL

    # The file to which current statements will be logged.
    currentLogFilename: /var/log/example/developer.log

    # When the log file rotates, the archived log will be renamed to this and gzipped. The
    # %d is replaced with the previous day (yyyy-MM-dd). Custom rolling windows can be created
    # by passing a SimpleDateFormat-compatible format as an argument: "%d{yyyy-MM-dd-hh}".
    archivedLogFilenamePattern: /var/log/example/developer-%d.log.gz

    # The number of archived files to keep.
    archivedFileCount: 5

    # The timezone used to format dates. HINT: USE THE DEFAULT, UTC.
    timeZone: UTC

We use XML and save configuration files in external resources (out of war/jar).

The configuration loading should not be a problem (even if you save it in database), because you don’t load it frequently (don’t you?). If you need update the configuration runtime, you can use file monitor API to get notified when file changed, or just a timer loop to pull data.

One option is store your configuration in a data base. This way you can change properties on the fly.

You don’t actually have to install something like MySQL or PostgreSQL, you can use something really minimal such as SQLite or H2.

You can also employ a JMX bean and you can modify it also on the fly.

Have you looked at Typesafe Config ? A quick list of features (taken from the link)

• implemented in plain Java with no dependencies
• supports files in three formats: Java properties, JSON, and a human-friendly JSON superset
• merges multiple files across all formats
• can load from files, URLs, or classpath
• good support for “nesting” (treat any subtree of the config the same as the whole config)
• users can override the config with Java system properties, java -Dmyapp.foo.bar=10
• supports configuring an app, with its framework and libraries, all from a single file such as application.conf
• parses duration and size settings, “512k” or “10 seconds”
• converts types, so if you ask for a boolean and the value is the string “yes”, or you ask for a float and the value is an int, it will figure it out.