Classloader hierarchy

The run-time environment of WAS uses these classloaders to find and load new classes for an application in this order:

1. JVM classloaders
   The JVM classloaders are provided by the Java runtime. JDK 1.3 provides 3 classloaders: boot classloader, extensions classloader and user classloader.

2. WebSphere extensions classloader
   The WAS run time is loaded by the WebSphere extensions classloader.

3. Application server classloaders
   You can optionally define application server classloaders to load code from shared libraries.

4. Application classloaders
   Your enterprise application code is loaded by one or more application classloaders.

Each classloader is a child of the classloader above it. That is, the application module classloaders are children of the WebSphere-specific extensions classloader, which is a child of the CLASSPATH Java classloader. Whenever a class needs to be loaded, delegation depends on the delegation mode setting, which always defaults to PARENT_FIRST, but can be changed to PARENT_LAST. If none of the parent classloaders can find the class, the original classloader attempts to load the class. Requests can only go to a parent classloader; they cannot go to a child classloader. For example, if a class in the WebSphere extension classloader tried to reference a class in an application classloader, it would not be found. After a class is loaded by a classloader, any new classes that it tries to load reuse the same classloader or go up the precedence list until the class is found.

The OS/400 JVM can run in two modes -- JIT (just in time compiler) and DE (direct execution). For more information on how these modes can be used by the different classloaders, see Java execution modes.