Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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();
env.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
env.setProperty(Context.PROVIDER_URL,
"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
-Djava.naming.provider.url=
ldap://localhost:389/o=developmentor, ou=java
YourApplication
Listing 3—Configuration in a Properties File
#file jndi.properties java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory 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.