How to solve java.lang.NoClassDefFoundError?

Question

I\'ve tried both the example in Oracle\'s Java Tutorials. They both compile fine, but at run-time, both come up with this error:

Exception in thread \"main\"         


        

Answer 1

In my environment, I encounter this issue in unit test. After appending one library dependency to *.pom, that's fixed.

e.g.:

error message:

java.lang.NoClassDefFoundError: com/abc/def/foo/xyz/Iottt

pom:

<dependency>
    <groupId>com.abc.def</groupId>
    <artifactId>foo</artifactId>
    <scope>test</scope>
</dependency>

Answer 2

if you are using gradlew, go to ./gradle/wrapper/gradle-wrapper.properties and change distributionUrl to the correct version of gradle.

If you are using JDK14 try

distributionUrl=https\://services.gradle.org/distributions/gradle-6.3-bin.zip

Answer 3

After working on a NetBeans project for many months, I suddenly got the NoClassDefFoundError message shortly after getting a "Low Memory" alert. Doing a Clean rebuild didn't help, but closing Netbeans altogether and reopening the project there were no error reports.

Answer 4

NoClassDefFoundError means that the class is present in the classpath at Compile time, but it doesn't exist in the classpath at Runtime.

If you're using Eclipse, make sure you have the shapes, linepoints and the spaceobjects as entries in the .classpath file.

Answer 5

If your project is in a package like com.blahcode and your class is called Main, the compiled files may be output in a directory structure like ./out/com/blahcode/Main.class. This is especially true for IntelliJ IDEA.

When trying to run from a shell or cmd, you need to cd to that which contains com as a sub-directory.

cd out
java -classpath . com.blahcode.Main

Answer 6

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.

// ClassLoaderTracer.java
// From: https://blogs.oracle.com/sundararajan/entry/tracing_class_loading_1_5

import java.lang.instrument.*;
import java.security.*;

// manifest.mf
// Premain-Class: ClassLoadTracer

// jar -cvfm tracer.jar manifest.mf ClassLoaderTracer.class

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

public class ClassLoadTracer 
{
    public static void premain(String agentArgs, Instrumentation inst) 
    {
        final java.io.PrintStream 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 
                Thread.dumpStack();

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