Class.forName() loads java file or .class file?

I am getting a NoClassDefFoundError when I run my Java application. What is typically the cause of this?


This is caused when there is a class file that your code depends on and it is present at compile time but not found at runtime. Look for differences in your build time and runtime classpaths.

While it's possible that this is due to a classpath mismatch between compile-time and run-time, it's not necessarily true.

It is important to keep two or three different exceptions straight in our head in this case:

  1. java.lang.ClassNotFoundException This exception indicates that the class was not found on the classpath. This indicates that we were trying to load the class definition, and the class did not exist on the classpath.
  2. java.lang.NoClassDefFoundError This exception indicates that the JVM looked in its internal class definition data structure for the definition of a class and did not find it. This is different than saying that it could not be loaded from the classpath. Usually this indicates that we previously attempted to load a class from the classpath, but it failed for some reason - now we're trying to use the class again (and thus need to load it, since it failed last time), but we're not even going to try to load it, because we failed loading it earlier (and reasonably suspect that we would fail again). The earlier failure could be a ClassNotFoundException or an ExceptionInInitializerError (indicating a failure in the static initialization block) or any number of other problems. The point is, a NoClassDefFoundError is not necessarily a classpath problem.

Here is the code to illustrate java.lang.NoClassDefFoundError.

public class NoClassDefFoundErrorDemo {
    public static void main(String[] args) {
        try {
            // The following line would throw ExceptionInInitializerError
            SimpleCalculator calculator1 = new SimpleCalculator();
        } catch (Throwable t) {
        // The following line would cause NoClassDefFoundError
        SimpleCalculator calculator2 = new SimpleCalculator();


public class SimpleCalculator {
    static int undefined = 1 / 0;

I have found that sometimes I get a NoClassDefFound error when code is compiled with an incompatible version of the class found at runtime. The specific instance I recall is with the apache axis library. There were actually 2 versions on my runtime classpath and it was picking up the out of date and incompatible version and not the correct one, causing a NoClassDefFound error. This was in a command line app where I was using a command similar to this.

set classpath=%classpath%;axis.jar

I was able to get it to pick up the proper version by using:

set classpath=axis.jar;%classpath%;

I was using spring framework with maven and solved this error in my project.

There was a runtime error in the class. I was reading a property as integer, but when it read the value from the property file, its value was double. Spring did not give me a full stack trace of on which line the runtime failed. It simply said NoClassDefFoundError. But when I executed it as a native Java Application (taking it out of MVC), it gave ExceptionInInitializerError which was the true cause and which is how I traced the error.

@xli's answer gave me insight into what may be wrong in my code.

This is the best solution I found so far.

Suppose we have a package called org.mypackage containing the classes:

  • HelloWorld (main class)
  • SupportClass
  • UtilClass

and the files defining this package are stored physically under the directory D:\myprogram (on Windows) or /home/user/myprogram (on Linux).

The file structure will look like this: Class.forName() loads java file or .class file?

When we invoke Java, we specify the name of the application to run: org.mypackage.HelloWorld. However we must also tell Java where to look for the files and directories defining our package. So to launch the program, we have to use the following command: Class.forName() loads java file or .class file?

I get NoClassFoundError when classes loaded by the runtime class loader cannot access classes already loaded by the java rootloader. Because the different class loaders are in different security domains (according to java) the jvm won't allow classes already loaded by the rootloader to be resolved in the runtime loader address space.

Run your program with 'java -javaagent:tracer.jar [YOUR java ARGS]'

It produces output showing the loaded class, and the loader env that loaded the class. It's very helpful tracing why a class cannot be resolved.

// From:

import java.lang.instrument.*;

// Premain-Class: ClassLoadTracer

// jar -cvfm tracer.jar ClassLoaderTracer.class

// java -javaagent:tracer.jar  [...]

public class ClassLoadTracer
    public static void premain(String agentArgs, Instrumentation inst)
        final out = System.out;
        inst.addTransformer(new ClassFileTransformer() {
            public byte[] transform(ClassLoader loader, String className, Class classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException {

                String pd = (null == protectionDomain) ? "null" : protectionDomain.getCodeSource().toString();
                out.println(className + " loaded by " + loader + " at " + new java.util.Date() + " in " + pd);

                // dump stack trace of the thread loading class

                // we just want the original .class bytes to be loaded!
                // we are not instrumenting it...
                return null;

I got this message after removing 2 files from the SRC library, and when I brought them back I kept seeing this Error message. My solution was:restart Eclipse. Since then I havn't seen this message again :-)

Category: java Time: 2008-08-29 Views: 1

Related post

iOS development

Android development

Python development

JAVA development

Development language

PHP development

Ruby development


Front-end development


development tools

Open Platform

Javascript development

.NET development

cloud computing


Copyright (C), All Rights Reserved.

processed in 0.117 (s). 12 q(s)