Property files offer an elegant solution for storing program settings loaded at runtime. The elegance comes from the hierarchical naming scheme, the ability to override settings on the command line, and the idea of default properties. Earlier generations of settings files like .rc (read command) or .ini (initialize) files lack these features. Default properties are underutilized, however, probably because good examples are rare and no tools support comparing and manipulation.
The problem with one big property file is that developers inevitably need conflicting settings, and the settings might significantly differ for coding, testing, and deployment. The most common way to express these conflicts, or shall I say, alternatives, is by including commented-out settings. But this strategy does not work well for automated builds, and writing comments about what part should be uncommented and why requires effort. Some try to solve this problem by creating many property files that have overlapping definitions, but this leads to the developer either editing many files to keep them consistent or enduring the inconsistencies as they crop up—both of which waste time. Another common way to accommodate differing properties is to set them on the command line, but this quickly grows messy, and who wants to commit messy start-up scripts to source code control to share usage examples?
