Classes are often loaded through a combination of explicit and implicit class loading. For example, a class loader could first load a class explicitly and then load all of its referenced classes implicitly.

Debugging features of the JVM
The previous section introduced the fundamental principles of class loading. This section covers the variety of features built into the IBM JVM to assist debugging. Other JVMs may have similar debugging features available; refer to the appropriate documentation for details.

Verbose outputYou can turn on the IBM JVM's verbose output by using the -verbose command-line option. Verbose output displays information on the console when certain events occur -- when a class has been loaded, for instance. For additional class loading information, you can use verbose class output. This is activated using the -verbose:class option.

Interpreting verbose output
Verbose output lists all the JAR files that have been opened and includes the full path to those JARs. Here's an example:

...
[Opened D:\jre\lib\core.jar in 10 ms]
[Opened D:\jre\lib\graphics.jar in 10 ms]
...

All the classes that are loaded are listed, along with the JAR file or directory from which they were loaded. For example:

...
[Loaded java.lang.NoClassDefFoundError from D:\jre\lib\core.jar]
[Loaded java.lang.Class from D:\jre\lib\core.jar]
[Loaded java.lang.Object from D:\jre\lib\core.jar]
...

Verbose class output shows additional information, such as when superclasses are being loaded, and when static initializers are being run. Some example output follows:

...
[Loaded HelloWorld from file:/C:/myclasses/]
[Loading superclass and interfaces of HelloWorld]
[Loaded HelloWorldInterface from file:/C:/myclasses/]
[Loading superclass and interfaces of HelloWorldInterface]
[Preparing HelloWorldInterface]
[Preparing HelloWorld]
[Initializing HelloWorld]
[Running static initializer for HelloWorld]
...

Verbose output also shows some internally thrown exceptions (if they occur), including the stack trace.

Resolving problems using -verbose
Verbose output can help to solve classpath problems, such as JAR files not being opened (and therefore not on the classpath) and classes being loaded from the wrong place.

IBM Verbose Class LoadingIt is often useful to know where class loaders look for classes and which class loader loads a particular class. You can obtain this information using the IBM Verbose Class Loading command-line option: -Dibm.cl.verbose=<class name>. You can use regular expressions to declare the name of the class; for instance, Hello* traces any classes with names starting with Hello.

This option also works on user-defined class loaders, as long as they directly or indirectly extend java.net.URLClassLoader.

Interpreting IBM Verbose Class Loading output
IBM Verbose Class Loading output shows the class loaders that attempt to load the specified class and the locations in which they look. For example, imagine we used the following command line:

java -Dibm.cl.verbose=ClassToTrace MainClass

Here, MainClass references ClassToTrace in its main method. This would produce output similar to the output here.

The class loaders are listed with parents before children because of the way that the standard delegation model works: Parents go first.

Notice that there is no output for the bootstrap class loader. Output is only produced for class loaders that extend java.net.URLClassLoader. Note also that class loaders are listed under their class name; if there are two instances of a class loader, it may not be possible to distinguish between them.

Resolving problems using IBM Verbose Class Loading
The IBM Verbose Class Loading option is a great way to check what the classpaths for all class loaders have been set to. It also indicates which class loader loads a given class and where it loads it from. This makes it easy to see if the correct version of a class is being loaded.

JavadumpA Javadump (also know as a Javacore) is another IBM diagnosis tool that you may find useful; to learn more about it, see the IBM Diagnostics Guide (see Resources for a link). A Javadump is generated by the JVM when one of the following events occurs:

• A fatal native exception occurs
• The JVM runs out of heap space
• A signal is sent to the JVM (for example, if Control-Break is pressed on Windows, or Control-\ on Linux)
• The com.ibm.jvm.Dump.JavaDump() method is called