A java.lang.NoSuchMethodError is a runtime error in Java which occurs when a method is called that exists at compile-time, but does not exist at runtime. The Java Garbage Collector (GC) cannot free up the space required for a new object, which causes a java.lang.OutOfMemoryError. This error can also be thrown when the native memory is insufficient to support the loading of a Java class.

What Causes java.lang.NoSuchMethodError

The java.lang.NoSuchMethodError occurs when an application does not find a called method at runtime. Some of the most common causes for ajava.lang.NoSuchMethodError are:

Breaking change in an third party library

If an application calls a method in a third party library, which exists at compile time but not at runtime, it can cause a java.lang.NoSuchMethodError. The third party library may have introduced a breaking change from one version to another - for example, it may have removed the method being called.

This usually indicates a problem with the build, since the method does exist at compile time but not at runtime. The version of the library used in the build may be different from the one used in the application code.

Breaking change within an application

A change in the class structure within an application can also cause a java.lang.NoSuchMethodError. This can happen in a multi-module application where a method may have been removed from the code in one module, which was called by another module.

This also indicates a problem with the build process, which may be referring to a different version of the called module.

Overriding third party library version

This can happen in case a third party library is used in an application, but not directly. For example, it could be a dependency of other third party libraries in the application, but which use different versions of the called library.

This can lead to a version conflict, resulting in a java.lang.NoSuchMethodError. Using build tools like Apache Maven and Gradle can prevent these kinds of version conflicts with their dependency management capabilities.

java.lang.NoSuchMethodError Example

Here is an example of java.lang.NoSuchMethodError thrown due to a breaking change introduced within an application.

Two classes will be created for this, the first of which is NoSuchMethodErrorExample which contains a method called print():

public class NoSuchMethodErrorExample {
    public void print(String myString) {
            System.out.println(myString);
        }   
}

The second class Main calls the print() method from NoSuchMethodErrorExample:

public class Main {
    public static void main(String[] args) {
            NoSuchMethodErrorExample nsmee = new NoSuchMethodErrorExample();
            nsmee.print("Hello World");
        }
}

When the Main class is executed, it produces the following output as expected:

Hello World

Now if the print() method is removed from the NoSuchMethodErrorExample class and only this class is recompiled, when the Main class is executed again, it throws a java.lang.NoSuchMethodError:

Exception in thread "main" java.lang.NoSuchMethodError: 'void NoSuchMethodErrorExample.print(java.lang.String)'
    at Main.main(Main.java:4)

The java.lang.NoSuchMethodError is thrown because the print() method is not found at runtime.

How to fix the java.lang.NoSuchMethodError

1. Full clean and compile

If a java.lang.NoSuchMethodError is encountered due to a breaking change within an application, a full clean and re-compilation of the project(s) containing both the calling and called classes should be performed. This will help make sure that the latest versions of the classes are used and resolve any inconsistencies.

2. Resolve third party library versioning issues

If a java.lang.NoSuchMethodError comes from calling a third party library method, finding out which library contains the called class and method can help detect inconsistent versioning between compile time and runtime dependencies.

The Java runtime option -verbose:class can be used to obtain information about the libraries used to load the called class. As an example, running the -verbose:class can produce the following output:

[0.009s][info][class,load] opened: /Library/Java/JavaVirtualMachines/jdk-14.0.2.jdk/Contents/Home/lib/modules
[0.015s][info][class,load] java.lang.Object source: shared objects file
[0.015s][info][class,load] java.io.Serializable source: shared objects file
[0.015s][info][class,load] java.lang.Comparable source: shared objects file
[0.015s][info][class,load] java.lang.CharSequence source: shared objects file
[0.016s][info][class,load] java.lang.constant.Constable source: shared objects file
[0.016s][info][class,load] java.lang.constant.ConstantDesc source: shared objects file
[0.016s][info][class,load] java.lang.String source: shared objects file

Examining the output can help figure out the version of the libraries used at runtime and resolve any inconsistencies.

Track, Analyze and Manage Java Errors With Rollbar

Rollbar in action

Managing errors and exceptions in your code is challenging. It can make deploying production code an unnerving experience. Being able to track, analyze, and manage errors in real-time can help you to proceed with more confidence. Rollbar automates Java error monitoring and triaging, making fixing errors easier than ever. Try it today.

How to Fix java.lang.NoSuchMethodError in Java

Table of Contents