Home > Articles > Programming > Java

  • Print
  • + Share This
From the author of

Properties Basics

Throughout Java's core API, properties are used to give users and administrators more control over their applications. Listings 1–3 show three approaches to configuring a context for the Java Naming and Directory Interface (JNDI).

Listing 1—Configuration Interlaced with Code

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import java.util.Properties;

public class TestProperties
 public Context getInitialContext() throws NamingException
  Properties env = new Properties();
          "ldap://localhost:389/o=developmentor, ou=java");
  return new InitialContext(env);

Listing 2—Configuration Passed on the Command Line

>java -Djava.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory 
      ldap://localhost:389/o=developmentor, ou=java 

Listing 3—Configuration in a Properties File

#file jndi.properties
java.naming.provider.url=ldap://localhost:389/o=developmentor, ou=java

In Listing 1, the Properties class is used to specify two name-value pairs that will be passed to the InitialContext constructor. The InitialContext constructor is a JNDI-provided factory method that loads different JNDI providers depending on the parameters passed in.

In Listing 2, these same name-value pairs are passed into the application on the command line that launches Java. The application (not shown here) can now simply call a no-arguments version of the InitialContext constructor, and the JNDI library will infer the necessary configuration information. Another variant, shown in Listing 3, is to specify the properties in a file called a properties file.

All three listings lead to the same result—loading a JNDI provider that accesses LDAP on the local machine. However, the first listing leaves all control in the hands of the developer, while the latter two listings shift control to whoever launches the application, such as an administrator or an end user. This shift has profound effects:

  • Certain kinds of changes are now far less expensive. If we want to change any aspect of the program's behavior that's controlled by a property, we don't need the services of a Java developer to do so.

  • By giving control to an administrator, we encourage black-box reuse. Our components can be configured for different scenarios without requiring any knowledge of the source code, or even of Java.

  • Configuration changes can be made on live deployment systems without a compile/debug/test cycle.

In short, separating configuration from code makes reuse more likely, makes modifications cheaper, and decouples configuration changes from the development cycle.

  • + Share This
  • 🔖 Save To Your Account