¿Cómo soluciono un error NoSuchMethodError?

Question

estoy recibiendo un NoSuchMethodError error al ejecutar mi programa Java.¿Qué pasa y cómo lo soluciono?

Answer 1

Sin más información, es difícil identificar el problema, pero la causa raíz es que lo más probable es que haya compilado una clase con una versión diferente de la clase a la que le falta un método que el que está utilizando al ejecutarla.

Mira el seguimiento de la pila...Si la excepción aparece al llamar a un método en un objeto en una biblioteca, lo más probable es que esté utilizando versiones independientes de la biblioteca al compilar y ejecutar.Asegúrate de tener la versión correcta en ambos lugares.

Si la excepción aparece al llamar a un método en objetos instanciados por clases tú hecho, entonces su proceso de construcción parece ser defectuoso.Asegúrese de que los archivos de clase que realmente está ejecutando estén actualizados cuando compila.

Answer 2

Estaba teniendo tu problema y así es como lo solucioné.Los siguientes pasos son una forma práctica de agregar una biblioteca.Hice bien los dos primeros pasos, pero no hice el último arrastrando el archivo ".jar" directamente desde el sistema de archivos a la carpeta "lib" de mi proyecto eclipse.Además, tuve que eliminar la versión anterior de la biblioteca tanto de la ruta de compilación como de la carpeta "lib".

Paso 1: agregue .jar para crear la ruta

Paso 2: asociar fuentes y javadocs (opcional)

Paso 3: arrastre el archivo .jar a la carpeta "lib" (no es opcional)

Answer 3

Tenga en cuenta que en el caso de la reflexión, se obtiene una NoSuchMethodException, mientras que con el código no reflectante, obtienes NoSuchMethodError.Tiendo a buscar en lugares muy diferentes cuando me enfrento a uno frente al otro.

Answer 4

Si tiene acceso para cambiar los parámetros de JVM, agregar una salida detallada debería permitirle ver qué clases se están cargando desde qué JAR.

java -verbose:class <other args>

Cuando se ejecuta su programa, la JVM debería volcar información estándar como:

...

[Cargado junit.framework.Assert desde el archivo:/C:/Program%20Files/junit3.8.2/junit.jar]

...

Answer 5

Esto generalmente ocurre cuando se usa un sistema de compilación como hormiga apache que solo compila archivos java cuando el archivo java es más nuevo que el archivo de clase.Si la firma de un método cambia y las clases usaban la versión anterior, es posible que las cosas no se compilen correctamente.La solución habitual es realizar una reconstrucción completa (normalmente "limpieza de hormigas" y luego "hormiga").

A veces, esto también puede deberse a que se compila con una versión de una biblioteca pero se ejecuta con una versión diferente.

Answer 6

Si usa experto u otro marco, y obtienes este error casi al azar, intenta una instalación limpia como...

clean install

Es especialmente probable que esto funcione si escribiste el objeto y sabes que tiene el método.Trabajó para mi.

Answer 7

Esto también puede ser el resultado del uso de la reflexión.Si tiene un código que se refleja en una clase y extrae un método por nombre (por ejemplo:con Class.getDeclaredMethod("someMethodName", .....)) entonces, cada vez que el nombre del método cambie, como durante una refactorización, deberá recordar actualizar los parámetros del método de reflexión para que coincidan con la firma del nuevo método, o el getDeclaredMethod la llamada arrojará un NoSuchMethodException.

Si este es el motivo, entonces el seguimiento de la pila debería mostrar el punto en el que se invoca el método de reflexión y solo necesitará actualizar los parámetros para que coincidan con la firma del método real.

En mi experiencia, esto surge ocasionalmente cuando la unidad prueba métodos/campos privados y usa un TestUtilities clase para extraer campos para la verificación de la prueba.(Generalmente con código heredado que no se diseñó teniendo en cuenta las pruebas unitarias).

Answer 8

Si está escribiendo una aplicación web, asegúrese de no tener versiones conflictivas de un jar en el directorio de biblioteca global de su contenedor y también en su aplicación.Es posible que no sepa necesariamente qué jar está utilizando el cargador de clases.

p.ej.

• tomcat/común/lib
• miaplicaciónweb/WEB-INF/lib

Answer 9

Estos problemas se deben al uso del mismo objeto en las mismas dos clases.Los objetos utilizados no contienen un nuevo método. Se ha agregado que la nueva clase de objeto contiene.

ex:

filenotnull=/DayMoreConfig.conf
16-07-2015 05:02:10:ussdgw-1: Open TCP/IP connection to SMSC: 10.149.96.66 at 2775
16-07-2015 05:02:10:ussdgw-1: Bind request: (bindreq: (pdu: 0 9 0 [1]) 900 900 GEN 52 (addrrang: 0 0 2000) ) 
Exception in thread "main" java.lang.NoSuchMethodError: gateway.smpp.PDUEventListener.<init>(Lgateway/smpp/USSDClient;)V
        at gateway.smpp.USSDClient.bind(USSDClient.java:139)
        at gateway.USSDGW.initSmppConnection(USSDGW.java:274)
        at gateway.USSDGW.<init>(USSDGW.java:184)
        at com.vinaphone.app.ttn.USSDDayMore.main(USSDDayMore.java:40)

-bash-3.00$ 

Estos problemas son causados ​​por la clase similar concomitante 02 (1 en src, 1 en el archivo jar aquí es gateway.jar)

Answer 10

Significa que el método respectivo no está presente en la clase:

1. Si está utilizando jar, descompile y verifique si la versión respectiva de jar tiene la clase adecuada.
2. Compruebe si ha compilado la clase adecuada de su fuente.

Answer 11

En mi caso, sucedió porque cambié el tipo de argumento en la función, del Objeto a a la Cadena a.Podría resolverlo limpiando y construyendo de nuevo.

Answer 12

Acabo de resolver este error reiniciando mi Eclipse y ejecutando la aplicación.El motivo de mi caso puede ser que reemplazo mis archivos fuente sin cerrar mi proyecto o Eclipse.Lo que provocó una versión diferente de las clases que estaba usando.

Answer 13

Pruebe de esta manera:elimine todos los archivos .class en los directorios de su proyecto (y, por supuesto, todos los subdirectorios).Reconstruir.

A veces mvn clean (si está utilizando maven) no limpia los archivos .class creados manualmente por javac.Y esos archivos antiguos contienen firmas antiguas, lo que lleva a NoSuchMethodError.

Answer 14

Simplemente agregando respuestas existentes.Estaba enfrentando este problema con Tomcat en eclipse.Cambié una clase y seguí los siguientes pasos,

1. Limpié y construí el proyecto en eclpise.

2. instalación limpia de mvn

3. Tomcat reiniciado

Aún así me enfrentaba al mismo error.Entonces Limpié Tomcat, limpié el directorio de trabajo de Tomcat. Reinicié el servidor y mi problema desapareció.Espero que esto ayude a alguien

Answer 15

Solucioné este problema en Eclipse cambiando el nombre de un archivo de prueba de Junit.
En mi espacio de trabajo de Eclipse tengo un proyecto de aplicación y un proyecto de prueba.
El proyecto de prueba tiene el proyecto de aplicación como proyecto obligatorio en la ruta de compilación.

Comenzó a recibir NoSuchMethodError.
Luego me di cuenta de que la clase del proyecto de prueba tenía el mismo nombre que la clase del proyecto de aplicación.

App/  
  src/
     com.example/  
       Projection.java
Test/  
  src/
     com.example/
       Projection.java

Después de cambiar el nombre de la prueba al nombre correcto "ProjectionTest.java", la excepción desapareció.

Answer 16

Me encontré con un problema similar cuando estaba cambiando las firmas de los métodos en mi aplicación.Limpiar y reconstruir mi proyecto resolvió el "NoSuchMethodError".

Answer 17

La respuesta anterior explica muy bien .. Solo para agregar una cosa Si está usando eclipse, use ctrl+shift+T e ingrese la estructura del paquete de la clase (p. ej.:gateway.smpp.PDUEventListener), encontrará todos los archivos/proyectos donde está presente.Elimine los archivos jar innecesarios de classpath o agréguelos arriba en classpath.Ahora seleccionará el correcto.

Answer 18

Me encontré con un problema similar.

Caused by: java.lang.NoSuchMethodError: com.abc.Employee.getEmpId()I

Finalmente identifiqué que la causa raíz era cambiar el tipo de datos de la variable.

1. Employee.java --> Contiene la variable (EmpId) cuyo tipo de datos ha sido cambiado de int a String.
2. ReportGeneration.java --> Recupera el valor usando el captador, getEmpId().

Se supone que debemos reagrupar el frasco incluyendo solo las clases modificadas.Como no hubo cambios en ReportGeneration.java Solo estaba incluyendo el Employee.class en el archivo Jar.Tuve que incluir el ReportGeneration.class archivo en el jar para resolver el problema.

Answer 19

He tenido el mismo problema.Esto también se produce cuando hay ambigüedad en las clases.Mi programa estaba intentando invocar un método que estaba presente en dos archivos JAR presentes en la misma ubicación/ruta de clase.Elimine un archivo JAR o ejecute su código de manera que solo se use un archivo JAR.Compruebe que no esté utilizando el mismo JAR o versiones diferentes del mismo JAR que contengan la misma clase.

DISP_E_EXCEPTION [paso] [] [Z-JAVA-105 Excepción de Java java.lang.NoSuchMethodError(com.example.yourmethod)]

Answer 20

Para responder a la pregunta original.Según documentos de Java aquí:

"NoSuchMethodError" Se lanza si una aplicación intenta llamar a un método específico de una clase (ya sea estática o de instancia) y esa clase ya no tiene una definición de ese método.

Normalmente, el compilador detecta este error;Este error sólo puede ocurrir en tiempo de ejecución si la definición de una clase ha cambiado de manera incompatible.

1. Si sucede en tiempo de ejecución, verifique que la clase que contiene el método esté en la ruta de clase.
2. Compruebe si ha agregado una nueva versión de JAR y si el método es compatible.

Answer 21

La mayoría de las veces, java.lang.NoSuchMethodError se detecta en el compilador, pero a veces puede ocurrir en tiempo de ejecución.Si este error ocurre en tiempo de ejecución, entonces la única razón podría ser el cambio en la estructura de clases que lo hizo incompatible.

Mejor explicación: https://www.journaldev.com/14538/java-lang-nosuchmethoderror

Answer 22

También encontré este error.

Mi problema fue que cambié la firma de un método, algo así como

void invest(Currency money){...}

en

void invest(Euro money){...}

Este método fue invocado desde un contexto similar a

public static void main(String args[]) {
    Bank myBank = new Bank();

    Euro capital = new Euro();
    myBank.invest(capital);
}

El compilador no dice nada sobre advertencias/errores, ya que el capital es tanto moneda como euro.

El problema apareció debido al hecho de que solo compilé la clase en la que se definió el método: Banco, pero no la clase desde la que se llama el método, que contiene el método main().

Este problema no es algo que pueda encontrarse con demasiada frecuencia, ya que lo más frecuente es que el proyecto se reconstruya manualmente o se active automáticamente una acción de compilación, en lugar de simplemente compilar la clase modificada.

Mi caso de uso fue que generé un archivo .jar que se iba a usar como revisión, que no contenía App.class ya que no se modificó.Para mí tenía sentido no incluirlo ya que mantuve la clase base del argumento inicial a través de la herencia.

La cuestión es que, cuando compilas una clase, el código de bytes resultante es una especie de estático, en otras palabras, es un referencia dura.

El código de bytes original desensamblado (generado con la herramienta javap) se ve así:

 #7 = Methodref          #2.#22         // Bank.invest:(LCurrency;)V

Después de que ClassLoader carga el nuevo Bank.class compilado, no encontrará dicho método, parece como si hubiera sido eliminado y no modificado, de ahí el error mencionado.

Espero que esto ayude.

Answer 23

El problema en mi caso fue tener dos versiones de la misma biblioteca en la ruta de compilación.La versión anterior de la biblioteca no tenía la función y la más nueva sí.

Answer 24

Tuve un problema similar con mi Proyecto Gradle usando Intelij.Lo resolví eliminando el paquete .gradle (ver captura de pantalla a continuación) y reconstruyendo el proyecto.Paquete .gradle

Answer 25

No existe tal error de método:Pasé un par de horas solucionando este problema, finalmente lo solucioné simplemente cambiando el nombre del paquete, limpiando y compilando...Pruebe primero una compilación limpia, si no funciona, intente cambiar el nombre del nombre de la clase o del paquete y realice una compilación limpia... debería arreglarse.Buena suerte.

Answer 26

Yo tenía el mismo error:

  Exception in thread "main" java.lang.NoSuchMethodError: com.fasterxml.jackson.core.JsonGenerator.writeStartObject(Ljava/lang/Object;)V
        at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:151)
        at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:292)
        at com.fasterxml.jackson.databind.ObjectMapper._configAndWriteValue(ObjectMapper.java:3681)
        at com.fasterxml.jackson.databind.ObjectMapper.writeValueAsString(ObjectMapper.java:3057)

Para solucionarlo comprobé, en primer lugar, Diagrama de dependencia del módulo (click in your POM the combination -> Ctrl+Alt+Shift+U o right click in your POM -> Maven -> Show dependencies) para comprender dónde estaba exactamente el conflicto entre bibliotecas (Intelij IDEA).En mi caso particular, tuve diferentes versiones de las dependencias de Jackson.

1) Entonces, agregué directamente en mi POM del proyecto explícitamente la versión más alta: 2.8.7 de estas dos.

En propiedades:

<jackson.version>2.8.7</jackson.version>

Y como dependencia:

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>${jackson.version}</version>
</dependency>

2) Pero también se puede resolver usando Exclusiones de dependencia.

Por el mismo principio que se muestra a continuación en el ejemplo:

  <dependency>
      <groupId>group-a</groupId>
      <artifactId>artifact-a</artifactId>
      <version>1.0</version>
          <exclusions>
             <exclusion>
                <groupId>com.fasterxml.jackson.core</groupId>
                <artifactId>jackson-databind</artifactId>
             </exclusion>
         </exclusions>
  </dependency>

La dependencia con una versión no deseada será excluida de su proyecto.

Answer 27

Si el nombre de su archivo es diferente al nombre de la clase que contiene el método principal, entonces existe la posibilidad de que este error cause.