Class loading is a fundamental aspect of the Java programming language. A Java programmer should definitely understand the lifecycle of a class, when it gets loaded, linked, intialized and unloaded. Class Loaders are primarily responsible for handling these. The JVM has a bootstrap loader that takes care of this. Custom Class loaders could be created and could be loaded by the bootstrap class loader from which point onwards the custom class loader can customize and handle the default class loader’s functionalities. For example the AppletClassLoader is responsibe for loading the applets over the net and displaying them on the browser. This class loader is loaded by the JRE on the browser system whenever an Applet tag is encountered in the page. The class loader architecture in JVM (Java Virtual Machine) is well explained by Bill Venners in “Inside JVM” book. You can take a look at the class loader architecture in the introduction chapter of the book available here in artima.

Class Loaders play an important role in application servers determining where to look for a class. The ability to create custom class loaders has paved way in the advancement of specialized containers in application servers. Most likely you would have heard of web container and ejb container, they all have custom class loaders to manage the classes specific to the containers. A key problem in the J2EE arena is to solve the class loading problems or to put it crude, the CNFE’s (ClassNotFoundException). The J2EE application structure has different components. When deployed to an application server, these are loaded by different class loaders. If you have deployed a J2EE application, you might have already set some classpath’s, system classpath’s and application class path’s. How the class loading happens? How is the path resolved? This wonderful article on “J2EE Class Loading Demystified” talks about the class loaders in the Websphere application server and how it works.