I prefer at this point not to use 3rd party libaries, especially large and complex projects with a lot of history, and especially for small subsystems that I’d rather keep as simple as possible.

I have been burned in the past with those kind of things, and unless I’m pressed for time and already know a tool – I roll my own.

Regarding the cache – its not a cache per-se in the since of the mechanism I described. It a registry for mechanisms. You “register” your plugin with the mechanism, and when clients request configuration data, your mechanism will be asked whether it can supply it. If it can’t then another plugin will be asked until either the data can be retrieved or all plugins are exahusted.

Regarding the configuration – I don’t think you completly understand the issue: there can be several configuration sources (or providers), for example the basic provider reads a properties file from a known location, while another may scan for property files on the classpath, another reads XML files and another fetches configuration from a database (or from an HTTP server; a hardware interface; your imagination is the limit). I don’t want to develop all these now, and I don’t want to preclude future development of additional providers.

I have put a lot of effort into future compatability in most software projects I’ve done, and time and time again it has proven itself to be incredibly helpful and to save tons of development time and money later, and I’m not shorthanding it this time either.