Home > Articles > Programming > Java

Java Properties Purgatory Part 1

  • Print
  • + Share This
Nonstandard component configuration interfaces (CCIs) for Java lead to wasted time and wasted code, and they make configuration-related bugs more likely. Part 1 of this 2 part series details the problems with using system properties to configure components.
Copyright 2002 by Stuart Halloway and DevelopMentor. This article originally appeared in DevelopMentor’s free white paper collection and is reprinted here with the permission of DevelopMentor and the author.
Like this article? We recommend


Application configuration deserves careful design—perhaps even more than application code. Unfortunately, the lion's share of effort, planning, and tool development goes into making code clean and elegant—with configuration and deployment left as an afterthought.

In Java, configuration often takes the form of properties. Although properties are better than nothing, using them in an ad hoc way leads to components that are unnecessarily difficult to deploy, maintain, and reuse. Part 1 of this article will do the following:

  • Explain how properties and property files are used

  • Introduce the key issues to consider when designing a component configuration interface (CCI)

  • Point out the weaknesses of the property-based CCIs for JNDI, RMI, and security

In Part 2, I'll do the following:

  • Introduce XML as a configuration option

  • Examine the weaknesses of current XML CCIs: the preferences API and J2EE container configuration

  • Propose a fresh start with a common CCI architecture for all Java components

  • + Share This
  • 🔖 Save To Your Account