java.lang.NoClassDefFoundError: Parent first Classloader

This is part 4 of our “Exception in thread main java.lang.NoClassDefFoundError” troubleshooting series. As you saw from my previous articles, missing Jar files and failure of static initializers are the most common sources of this problem. However, sometimes the root cause is due to a more complex Java class loader problem which is quite common when developing Java EE applications involving multiple parent and child class loaders. The following article will describe one common problem pattern when using the default class loader delegation model.

A simple Java program will again be provided in order to help you understand this problem pattern.

Default JVM Classloader delegation model

As we saw from the first article, the default class loader delegation model is from bottom-up e.g. parent first. This means that the JVM is going up to the class loader chain in order to find and load each of your application Java classes. If the class is not found from the parent class loaders, the JVM will then attempt to load it from the current Thread context class loader; typically a child class loader.

NoClassDefFoundError problems can occur, for example, when you wrongly package your application (or third part API’s) between the parent and child class loaders. Another example is code / JAR files injection by the container itself or third party API’s deployed at a higher level in the class loader chain.

In the above scenarios:

• The JVM loads one part of the affected code to a parent class loader (SYSTEM or parent class loaders)
• The JVM loads the other parts of the affected code to a child class loader (Java EE container or application defined class loader)

Now what happens when Java classes loaded from the parent attempt to load reference classes deployed only to the child classloader? NoClassDefFoundError!

Please remember that a parent class loader has no visibility or access to child class loaders. This means that any referencing code must be found either from the parent class loader chain (bottom-up) or at the current Thread context class loader level; otherwise java.lang.NoClassDefFoundError is thrown by the JVM.

This is exactly what the following Java program will demonstrate.

Sample Java program

The following simple Java program is split as per below:

• The main Java program NoClassDefFoundErrorSimulator is packaged in MainProgram.jar
• A logging utility class JavaEETrainingUtil is packaged in MainProgram.jar
• The Java class caller CallerClassA is packaged in caller.jar
• The referencing Java class ReferencingClassA is packaged in referencer.jar

These following tasks are performed:

• Create a child class loader (java.net.URLClassLoader)
• Assign the caller and referencing Java class jar files to the child class loader
• Change the current Thread context ClassLoader to the child ClassLoader
• Attempt to load and create a new instance of CallerClassA from the current Thread context class loader e.g. child
• Proper logging was added in order to help you understand the class loader tree and Thread context class loader state

It will demonstrate that a wrong packaging of the application code is leading to a NoClassDefFoundError as per the default class loader delegation model.

** JavaEETrainingUtil source code can be found from the article part #2

#### NoClassDefFoundErrorSimulator.java

package org.ph.javaee.training3;

import java.net.URL;

import java.net.URLClassLoader;

import org.ph.javaee.training.util.JavaEETrainingUtil;

/**

 * NoClassDefFoundErrorSimulator

 * @author Pierre-Hugues Charbonneau

 *

 */

public class NoClassDefFoundErrorSimulator {

       

        /**

         * @param args

         */

        public static void main(String[] args) {

              

               System.out.println("java.lang.NoClassDefFoundError Simulator - Training 3");

               System.out.println("Author: Pierre-Hugues Charbonneau");

               System.out.println("http://javaeesupportpatterns.blogspot.com");

              

               // Local variables

               String currentThreadName = Thread.currentThread().getName();

               String callerFullClassName = "org.ph.javaee.training3.CallerClassA";

              

               // Print current ClassLoader context & Thread

               System.out.println("\nCurrent Thread name: '"+currentThreadName+"'");

               System.out.println("Initial ClassLoader chain: "+JavaEETrainingUtil.getCurrentClassloaderDetail());

              

               try {

                       // Location of the application code for our child ClassLoader

                       URL[] webAppLibURL = new URL[] {new URL("file:caller.jar"),new URL("file:referencer.jar")};

                      

                       // Child ClassLoader instance creation              

                       URLClassLoader childClassLoader = new URLClassLoader(webAppLibURL);

                      

                       /*** Application code execution... ***/

                      

                       // 1. Change the current Thread ClassLoader to the child ClassLoader

                       Thread.currentThread().setContextClassLoader(childClassLoader);

                       System.out.println(">> Thread '"+currentThreadName+"' Context ClassLoader now changed to '"+childClassLoader+"'");

                       System.out.println("\nNew ClassLoader chain: "+JavaEETrainingUtil.getCurrentClassloaderDetail());

                      

                       // 2. Load the caller Class within the child ClassLoader...

                       System.out.println(">> Loading '"+callerFullClassName+"' to child ClassLoader '"+childClassLoader+"'...");

                       Class<?> callerClass = childClassLoader.loadClass(callerFullClassName);

                      

                       // 3. Create a new instance of CallerClassA

                       Object callerClassInstance = callerClass.newInstance();                    

                      

               } catch (Throwable any) {

                       System.out.println("Throwable: "+any);

                       any.printStackTrace();

               }

              

               System.out.println("\nSimulator completed!");

        }

}

#### CallerClassA.java

package org.ph.javaee.training3;

import org.ph.javaee.training3.ReferencingClassA;

/**

 * CallerClassA

 * @author Pierre-Hugues Charbonneau

 *

 */

public class CallerClassA {

       

        private final static Class<CallerClassA> CLAZZ = CallerClassA.class;

       

        static {

               System.out.println("Class loading of "+CLAZZ+" from ClassLoader '"+CLAZZ.getClassLoader()+"' in progress...");

        }

       

        public CallerClassA() {

               System.out.println("Creating a new instance of "+CallerClassA.class.getName()+"...");

              

               doSomething();

        }

       

        private void doSomething() {

              

               // Create a new instance of ReferencingClassA

               ReferencingClassA referencingClass = new ReferencingClassA();             

        }

}

#### ReferencingClassA.java

package org.ph.javaee.training3;

/**

 * ReferencingClassA

 * @author Pierre-Hugues Charbonneau

 *

 */

public class ReferencingClassA {

       

        private final static Class<ReferencingClassA> CLAZZ = ReferencingClassA.class;

       

        static {

               System.out.println("Class loading of "+CLAZZ+" from ClassLoader '"+CLAZZ.getClassLoader()+"' in progress...");

        }

       

        public ReferencingClassA() {

               System.out.println("Creating a new instance of "+ReferencingClassA.class.getName()+"...");

        }

       

        public void doSomething() {

               //nothing to do...

        }

}

Problem reproduction

In order to replicate the problem, we will simply “voluntary” split the packaging of the application code (caller & referencing class) between the parent and child class loader.

For now, let’s run the program with the right JAR files deployment and class loader chain:

• The main program and utility class are deployed at the parent class loader (SYSTEM classpath)
• CallerClassA and ReferencingClassA and both deployed at the child class loader level

## Baseline (normal execution)

<JDK_HOME>\bin>java -classpath MainProgram.jar org.ph.javaee.training3.NoClassDefFoundErrorSimulator

java.lang.NoClassDefFoundError Simulator - Training 3

Author: Pierre-Hugues Charbonneau

http://javaeesupportpatterns.blogspot.com

Current Thread name: 'main'

Initial ClassLoader chain:

-----------------------------------------------------------------

sun.misc.Launcher$ExtClassLoader@17c1e333

--- delegation ---

sun.misc.Launcher$AppClassLoader@214c4ac9 **Current Thread 'main' Context ClassLoader**

-----------------------------------------------------------------

>> Thread 'main' Context ClassLoader now changed to 'java.net.URLClassLoader@6a4d37e5'

New ClassLoader chain:

-----------------------------------------------------------------

sun.misc.Launcher$ExtClassLoader@17c1e333

--- delegation ---

sun.misc.Launcher$AppClassLoader@214c4ac9

--- delegation ---

java.net.URLClassLoader@6a4d37e5 **Current Thread 'main' Context ClassLoader**

-----------------------------------------------------------------

>> Loading 'org.ph.javaee.training3.CallerClassA' to child ClassLoader 'java.net.URLClassLoader@6a4d37e5'...

Class loading of class org.ph.javaee.training3.CallerClassA from ClassLoader 'java.net.URLClassLoader@6a4d37e5' in progress...

Creating a new instance of org.ph.javaee.training3.CallerClassA...

Class loading of class org.ph.javaee.training3.ReferencingClassA from ClassLoader 'java.net.URLClassLoader@6a4d37e5' in progress...

Creating a new instance of org.ph.javaee.training3.ReferencingClassA...

Simulator completed!

For the initial run (baseline), the main program was able to create successfully a new instance of CallerClassA from the child class loader (java.net.URLClassLoader) along with its referencing class with no problem.

Now let’s run the program with the wrong application packaging and class loader chain:

• The main program and utility class are deployed at the parent class loader (SYSTEM classpath)
• CallerClassA and ReferencingClassA and both deployed at the child class loader level
• CallerClassA (caller.jar) is also deployed at the parent class loader level

## Problem reproduction run (static variable initializer failure)

<JDK_HOME>\bin>java -classpath MainProgram.jar;caller.jar org.ph.javaee.training3.NoClassDefFoundErrorSimulator

java.lang.NoClassDefFoundError Simulator - Training 3

Author: Pierre-Hugues Charbonneau

http://javaeesupportpatterns.blogspot.com

Current Thread name: 'main'

Initial ClassLoader chain:

-----------------------------------------------------------------

sun.misc.Launcher$ExtClassLoader@17c1e333

--- delegation ---

sun.misc.Launcher$AppClassLoader@214c4ac9 **Current Thread 'main' Context ClassLoader**

-----------------------------------------------------------------

>> Thread 'main' Context ClassLoader now changed to 'java.net.URLClassLoader@6a4d37e5'

New ClassLoader chain:

-----------------------------------------------------------------

sun.misc.Launcher$ExtClassLoader@17c1e333

--- delegation ---

sun.misc.Launcher$AppClassLoader@214c4ac9

--- delegation ---

java.net.URLClassLoader@6a4d37e5 **Current Thread 'main' Context ClassLoader**

-----------------------------------------------------------------

>> Loading 'org.ph.javaee.training3.CallerClassA' to child ClassLoader 'java.net.URLClassLoader@6a4d37e5'...

Class loading of class org.ph.javaee.training3.CallerClassA from ClassLoader 'sun.misc.Launcher$AppClassLoader@214c4ac9' in progress...// Caller is loaded from the parent class loader, why???

Creating a new instance of org.ph.javaee.training3.CallerClassA...

Throwable: java.lang.NoClassDefFoundError: org/ph/javaee/training3/ReferencingClassA

java.lang.NoClassDefFoundError: org/ph/javaee/training3/ReferencingClassA

        at org.ph.javaee.training3.CallerClassA.doSomething(CallerClassA.java:27)

        at org.ph.javaee.training3.CallerClassA.<init>(CallerClassA.java:21)

        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

        at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)

        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)

        at java.lang.reflect.Constructor.newInstance(Unknown Source)

        at java.lang.Class.newInstance0(Unknown Source)

        at java.lang.Class.newInstance(Unknown Source)

        at org.ph.javaee.training3.NoClassDefFoundErrorSimulator.main(NoClassDefFoundErrorSimulator.java:51)

Caused by: java.lang.ClassNotFoundException: org.ph.javaee.training3.ReferencingClassA

        at java.net.URLClassLoader$1.run(Unknown Source)

        at java.net.URLClassLoader$1.run(Unknown Source)

        at java.security.AccessController.doPrivileged(Native Method)

        at java.net.URLClassLoader.findClass(Unknown Source)

        at java.lang.ClassLoader.loadClass(Unknown Source)

        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)

        at java.lang.ClassLoader.loadClass(Unknown Source)

        ... 9 more

Simulator completed!

What happened?

• The main program and utility classes were loaded as expected from the parent class loader (sun.misc.Launcher$AppClassLoader)
• The Thread context class loader was changed to child class loader as expected which includes both caller and referencing jar files
• However, we can see that CallerClassA was actually loaded by the parent class loader (sun.misc.Launcher$AppClassLoader) instead of the child class loader
• Since ReferencingClassA was not deployed to the parent class loader, the class cannot be found from the current class loader chain since the parent  class loader has no visibility on the child class loader, NoClassDefFoundError is thrown

The key point to understand at this point is why CallerClassA was loaded by the parent class loader. The answer is with the default class loader delegation model. Both child and parent class loaders contain the caller JAR files. However, the default delegation model is always parent first which is why it was loaded at that level. The problem is that the caller contains a class reference to ReferencingClassA which is only deployed to the child class loader; java.lang.NoClassDefFoundError condition is met.

As you can see, a packaging problem of your code or third part API can easily lead to this problem due to the default class loader delegation behaviour. It is very important that you review your class loader chain and determine if you are at risk of duplicate code or libraries across your parent and child class loaders.

Recommendations and resolution strategies

Now find below my recommendations and resolution strategies for this problem pattern:

• Review the java.lang.NoClassDefFoundError error and identify the Java class that the JVM is complaining about
• Review the packaging of the affected application(s), including your Java EE container and third part API’s used. The goal is to identify duplicate or wrong deployments of the affected Java class at runtime (SYSTEM class path, EAR file, Java EE container itself etc.).
• Once identified, you will need to remove and / or move the affected library/libraries from the affected class loader (complexity of resolution will depend of the root cause).
• Enable JVM class verbose e.g. –verbose:class. This JVM debug flag is very useful to monitor the loading of the Java classes and libraries from the Java EE container your applications. It can really help you pinpoint duplicate Java class loading across various applications and class loaders at runtime

Please feel free to post any question or comment. The next and last article of this series will focus on NoClassDefFoundError when using the “child first” delegation model.

Posted in: ClassLoader,Java