Class Loading

---

Java applications, including web applications, are built from a collection of classes at run time, not at development time. The programs are built from classes loaded into memory by classloaders. This means that we can factor-out classes that are common to many applications and deploy them in a central location, to be found and loaded into those applications only when they are needed. This means:

• Applications can be much smaller

• We can change generic (non application-specific) behavior globally, without the need to recompile and redeploy individual applications

We'll concentrate on the second of these. We'll investigate how the Java Virtual Machine (JVM) looks for classes at run time; the locations that it looks in; and the order that it looks in different locations. Once we understand this, we'll be able to ensure that our applications work the way we intend them to.

Here are some typical statements that will result in a class being loaded. In the first case we would probably assume the StringBuffer class to be a standard Java runtime class, to be loaded from the runtime library rt.jar:

     StringBuffer sb = new StringBuffer("This will load into memory"); 

In this case we would probably assume class Bank to be specific to our application, contained in the application's JAR file:

     Bank theBank = new Bank ("BigBank"); 

In this case we probably would expect the JDBC driver class to be used by many applications and hence deployed in a common location:

     Class.forName("org.gjt.mm.msql.Driver"); 

The JVM makes no such assumptions and there's nothing in these statements to indicate that the classes should be loaded from specific locations. The decision on where to look for classes is the responsibility of the classloader, or rather, the chain of classloaders.

Classloaders exist in chain. Each classloader has its own special way of finding classes at a specific location (for example in the application's JAR file, in a library .jar file, from a URL, or in the standard Java runtime library).

If the current classloader can find and load the required class, it will. If it can't it will ask its parent, which might ask its parent, and so on up the chain until the class is found and loaded, or the end of the chain is reached.

What does this mean for web applications? Firstly it means that we must deploy our application-specific classes and application-independent classes in one of the locations that the servlet container's chain of classloaders will look for them - otherwise the classes will not be found at all.

Secondly, it means that we need to take special care if classes with the same name, but different implementations are deployed in more than one place. The behavior of our application will depend on which version of the class is actually loaded.

Thirdly, it means that we need to understand the scope of a class (in particular, the scope of its static variables) according to the location from which it is loaded. The logic of an application may be adversely affected by simply deploying a class in the wrong place.

---