All naming operations are relative to a context. The initial context implements the Context interface and provides the starting point for resolution of names.

When the initial context is constructed, its environment is initialized with properties defined in the environment parameter passed to the constructor, and in any application resource files. In addition, a small number of standard JNDI properties may be specified as system properties or as applet parameters (through the use of Context.APPLET). These special properties are listed in the field detail sections of the Context and LdapContext interface documentation.

JNDI determines each property's value by merging the values from the following two sources, in order:

1. The first occurrence of the property from the constructor's environment parameter and (for appropriate properties) the applet parameters and system properties.
2. The application resource files (jndi.properties).

The initial context implementation is determined at runtime. The default policy uses the environment property "java.naming.factory.initial", which contains the class name of the initial context factory. An exception to this policy is made when resolving URL strings, as described below.

When a URL string (a String of the form scheme_id:rest_of_name) is passed as a name parameter to any method, a URL context factory for handling that scheme is located and used to resolve the URL. If no such factory is found, the initial context specified by "java.naming.factory.initial" is used. Similarly, when a CompositeName object whose first component is a URL string is passed as a name parameter to any method, a URL context factory is located and used to resolve the first name component. See NamingManager.getURLContext() for a description of how URL context factories are located.

This default policy of locating the initial context and URL context factories may be overridden by calling NamingManager.setInitialContextFactoryBuilder().

NoInitialContextException is thrown when an initial context cannot be instantiated. This exception can be thrown during any interaction with the InitialContext, not only when the InitialContext is constructed. For example, the implementation of the initial context might lazily retrieve the context only when actual methods are invoked on it. The application should not have any dependency on when the existence of an initial context is determined.

When the environment property "java.naming.factory.initial" is non-null, the InitialContext constructor will attempt to create the initial context specified therein. At that time, the initial context factory involved might throw an exception if a problem is encountered. However, it is provider implementation-dependent when it verifies and indicates to the users of the initial context any environment property- or connection- related problems. It can do so lazily--delaying until an operation is performed on the context, or eagerly, at the time the context is constructed.

An InitialContext instance is not synchronized against concurrent access by multiple threads. Multiple threads each manipulating a different InitialContext instance need not synchronize. Threads that need to access a single InitialContext instance concurrently should synchronize amongst themselves and provide the necessary locking.