How to Resolve java.lang.NoClassDefFoundError

Exception in thread "main" java.lang.NoClassDefFoundError is one of the common and difficult problems that you can face when developing Java EE enterprise or standalone Java applications. The complexity of the root cause analysis and resolution process mainly depend of the size of your Java EE middleware environment; especially given the high number of ClassLoaders present across the various Java EE applications.

What I’m proposing to you is a series of articles which will provide you with a step by step approach on how to troubleshoot and resolve such problem. I will also share the most common Java NoClassDefFoundError problem patterns I have observed over the last 10 years. Sample Java programs will also be available in order to simplify your learning process. I also encourage you to post comments, share your problem case and ask me any question on this subject.

The part 1 of the series will focus on a high level overview of this Java runtime error along with a Java ClassLoader overview.

java.lang.NoClassDefFoundError – what is it?

Now let’s begin what a simple overview of this problem. This runtime error is thrown by the JVM when there is an attempt by a ClassLoader to load the definition of a Class (Class referenced in your application code etc.) and when such Class definition could not be found within the current ClassLoader tree.

Basically, this means that such Class definition was found at compiled time but is not found at runtime.

Simple enough, what about adding the missing Class to the classpath?

Well not so fast, this type of problem is not that simple to fix. Adding the missing Class / JAR to your runtime application classpath / ClassLoader is just one of the many possible solutions. The key is to perform proper root cause analysis first. This is exactly why I’m creating this whole series.

For now, just keep in mind that this error does not necessarily mean that you are missing this Class definition from your “expected” classpath or ClassLoder so please do not assume anything at this point.

Java ClassLoader overview

Before going any further, it is very important that you have a high level of understanding of the Java ClassLoader principles. Quite often individuals debugging NoClassDefFoundError problems are struggling because they are lacking proper knowledge and understanding of Java ClassLoader principles; preventing them to pinpoint the root cause.

A class loader is a Java object responsible for loading classes. Basically a class loader attempts to locate or generate data that constitutes a definition for the class. One of the key points to understand is that Java class loaders by default use a delegation model to search for classes. Each instance of ClassLoader has an associated parent class loader. So let’s say that your application class loader needs to load class A. The first thing that it will attempt to do is to delegate the search for Class A to its parent class loader before attempting to find the Class A itself. You can end up with a large class loader chain with many parent class loaders up to the JVM system classpath bootstrap class loader.

What is the problem? Well if Class A is found from a particular parent class loader then it will be loaded by such parent which open the doors for NoClassDefFoundError if you are expecting Class A to be loaded by your application (child) class loader. For example, third part JAR file dependencies could only be present to your application child class loader.

Now let’s visualize this whole process in the context of a Java EE enterprise environment so you can better understand.

As you can see, any code loaded by the child class loader (Web application) will first delegate to the parent class loader (Java EE App). Such parent class loader will then delegate to the JVM system class path class loader. If no such class is found from any parent class loader then the Class will be loaded by the child class loader (assuming that the class was found).

Please note that Java EE containers such as Oracle Weblogic have mechanisms to override this default class loader delegation behavior. I will get back to this in the future articles.

Please feel free to post any comment or question of what you learned so far.

The part 2 will follow shortly.