1. Overview

In this article, we’ll demonstrate the reason behind NoSuchFieldError and discover how to resolve it.

2. NoSuchFieldError

As the name suggests, NoSuchFieldError occurs when a specified field doesn’t exist. NoSuchFieldError extends the IncompatibleClassChangeError class and is thrown when the application tries to access or modify a field of an object or a static field of a class but the object or class no longer has that field.

IncompatibleClassChangeError class extends the LinkageError class and occurs when we perform incompatible class definition changes. Finally, LinkageError extends Error and shows that a class has some dependency on another incompatibly changed class.

Let’s see this error in action with the help of an example. As a first step, let’s create a Dependency class:

public class Dependency {
    public static String message = "Hello Baeldung!!";

Then we’ll create a FieldErrorExample class that refers to a field of our Dependency class:

public class FieldErrorExample {
    public static String getDependentMessage() {
        return Dependency.message;

Let’s also add code to check whether we’re getting a message from the Dependency class:

public static void fetchAndPrint() {

Now, we can compile these files using the javac command, and upon execution of the FieldErrorExample class using the java command, it will print the specified message.

However, if we comment out, remove, or change the attribute name in the Dependency class and recompile it, then we’ll run into our error.

For example, let’s change the attribute name in our Dependency class:

public class Dependency {
    public static String msg = "Hello Baeldung!!";

Now, if we recompile only our Dependency class, and then execute FieldErrorExample again, we’ll encounter the NoSuchFieldError:

Exception in thread "main" java.lang.NoSuchFieldError: message

The above error occurred because the FieldErrorExample class still refers to the static field message of the Dependency class, but it no longer exists — we’ve made an incompatible change to the Dependency class.

3. Resolving the Error

To avoid this error, we need to clean and compile the existing files. We can do this using the javac command or with Maven by running mvn clean install. By performing this step, we’ll have all the latest compiled files, and we’ll avoid running into the error.

If the error persists, then the problem might be multiple JAR files: one while compiling, and another while running. This often happens when the application depends on external JARs. Here, we should validate the order of the JARs in the build path to identify the inconsistent JAR.

If we have to investigate further, it’s helpful to run the application with -verbose: class option to check the loaded classes. This can help us identify the outdated class.

Sometimes a third-party JAR might be internally referring to another version, which results in NoSuchFieldError. If this happens, we can use mvn dependency:tree -Dverbose. This generates the maven dependency tree and helps us in identifying the inconsistent JAR.

4. Conclusion

In this short tutorial, we have shown why NoSuchFieldError occurs and looked at how we can resolve it.

As always, the code is available over on GitHub.

Course – LS (cat=Java)

Get started with Spring and Spring Boot, through the Learn Spring course:

res – REST with Spring (eBook) (everywhere)
Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.