Class Loading In Java/J2EE

Class Loaders are a powerful mechanism for dynamically loading software components ie a class on the java platform. Lets us see an example below.

————————————————
Class C
{

D d  = new D();

}
———————————————–
There are two important things worth for our attention. First, assuming the class loader L loads the class C, then jvm will use the same class loader to load the class referenced by C. Before, the JVM allocates the object of class D, it must first resolve the symbolic reference of D. Other point is that ‘Delegation’ model is followed for class loading. A class loader can ask another class loader to load class on its behalf and a class type is uniquely determined by ‘Class Name with package + Loader’.

Each class object contains a reference to its defining loader and each loader refers to all the classes it defines. Classes are un-loaded when their defining  loader is garbage collected.

Regular Java applications running from command line involve three classloaders – Bootstrap, Extensions and System-Classpath classloaders.

– Bootstrap classloader is the parent of all classloaders and loads the standard JDK classes in lib directory of JRE (rt.jar).

– Extensions Classloader is the immediate child of Bootstrap classloader. This classloader loads the classes in lib/ext directory of the JRE or java.ext.dirs system property.

– System-Classpath classloader is the immediate child of Extensions classloader. It loads the classes and jars specified by the CLASSPATH environment variable, java.class.path system property, -cp or –classpath command line settings. If any of the jars specified in one of the above manner have a MANIFEST.MF file with a Class-Path attribute, the jars specified by the Class-Path attribute are also loaded.

It is therefore following points must be taken into consideration while writing custom class loaders.

– subclass of java.lang.ClassLoader
– implement loadClass()
– check if the class requested is already loaded, or check if a system class
– Define class for VM and resolve it.
– Return the class to caller.

J2EE class loader hierarchy:

In J2EE, each application is packaged as an Enterprise ARchive (EAR). The EAR is a self-contained deployment unit having minimal dependencies on external classes (with the exception of application server classes).  Each EAR gets its own classloader.

Let us start with the structure of EAR,an EAR file may contain following components.

– application.xml – XML file describing the contents of the EAR.

– EJB-JAR – Each EJB-JAR can contain one or more EJBs

– WAR – Each WAR contains exactly one web application.

– Dependency JAR – Normal JAR file containing classes that are shared between web and ejb application. It can also be a third party library used by both web and ejb application.

The following figure below clarifies class loading hierarchy,

FIGURE:

Some points to note,

1. The A.jar and B.jar are located within the same EAR containing the EJB-JAR. The EAR classloader loads them, but they become visible to the EJB classloader (a child of EAR classloader), when the EJB-JAR references these jars in its manifest file.

2.All of the WAR classloaders however inherit from the same parent viz. EJB classloader. The rationale behind this hierarchy is that EJBs contain the core of the business logic and web applications have to “see” them to invoke their business methods. Of course to “see” them the WAR manifest file has to have an entry as shown earlier.

We will see how configurations can be done in server and what are the parameters available for customizing class loading policies.

Happy Learning !!!