java.lang.NoSuchMethodError

No Such Method Error:

If you have a look at the error message java.lang.NoSuchMethodError  you may understand that the Java Virtual Machine is trying to indicate us that the method you invoked is not available in the class or in an interface.


You could have also seen this error thrown when executing a class that has no public static void main() method.To know the reason behind this read this post.

When you try to invoke a method that is no longer available in a class then at the compile time itself you will be shown an error message "cannot find symbol". So you may think how come this error is thrown when launching  a program or an application.

I have explained the fact behind this issue using the following programs.

Let's have a class Nomethod and Pro1 as follows,

Nomethod class:

import java.util.*;

class Nomethod

{

public static void main(String args[])

{

Pro1 s=new Pro1();

s.display();

}

}

Pro1 class:

class Pro1

{

public void display()

{

System.out.println("I am inside display");

}

}

When you execute this program it will work fine without showing any errors.Now look at what happens when i change the  class Pro1 as follows and compile this class alone.

Example1:

class Pro1

{

}

Example2:

class Pro1

{

public int void display()

{

System.out.println("I am inside display");

return 1; // for example i have included a statement  like this

}

}

Now if you execute the class Nomethod without recompiling it then you will be embarrassed by this java.lang.NoSuchMethodError at run-time.

1. If you change the class Pro1 as  shown in Example1,then this exception will be  thrown because there is no method display() available in that class.

 2. If you consider the Example2 this error is thrown because the signature of the method display() has been changed.

If you understand this examples then you might have understood the reason for this error thrown when executing a class that has no main() method.

The real fact is that "binary compatibility with the pre-existing binaries(classes) have been compromised by the new binaries(modified classes)". 

"when you change the signature of a method or delete a method in a particular class" and compile it alone then other classes that invokes this method will have no idea about the state of the method,thus causing this error to be thrown at run-time.

The same case applies to interfaces also,"if you try to change the signature of a method  or delete a method in the interface" at that time  also this exception will be thrown.

What could be the solution for this?

"If you have recompiled the other class, that invokes this modified method or deleted method in the class or in an interface" then this error will be shown at the compile-time itself and you can do the necessary steps to resolve it.

Note:

Things may get even worse,consider a situation like even if you recompile the class you will not be indicated of this error.What will you do?...

Say,for an example you include a older version of the package in your project and you have placed it in the extension library.You also have the newer package(in which the signature of the method has been changed) and you have included that package in the class path.

When compiling the classes the compiler will search for the classes in the extension libraries and bootstrap libraries to resolve the references,but the java virtual machine searches only in the class path(for third-party libraries) that has been specified.

So when using a new package in your application,ensure that the settings relevant to the older version had been modified and read the documentation of the newer package to know the changes that has been made in this package.