has - java error java lang nosuchmethoderror
¿Cómo arreglo un NoSuchMethodError? (21)
La mayoría de las veces java.lang.NoSuchMethodError es capturado como compilador, pero a veces puede ocurrir en tiempo de ejecución. Si este error ocurre en el tiempo de ejecución, la única razón podría ser el cambio en la estructura de la clase que lo hizo incompatible.
La mejor explicación: https://www.journaldev.com/14538/java-lang-nosuchmethoderror
NoSuchMethodError
un error NoSuchMethodError
al ejecutar mi programa Java. ¿Qué pasa y cómo lo soluciono?
Acabo de resolver este error reiniciando mi Eclipse y ejecutando la aplicación. El motivo de mi caso puede deberse a que reemplazo mis archivos fuente sin cerrar mi proyecto o Eclipse. Lo cual causó una versión diferente de las clases que estaba usando.
Esto generalmente se produce cuando se usa un sistema de compilación como Apache Ant 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 hacer una reconstrucción completa (generalmente "ant limpieza" y luego "hormiga").
A veces, esto también puede ser causado al compilar contra una versión de una biblioteca pero ejecutándose contra una versión diferente.
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 su nombre (por ejemplo: con Class.getDeclaredMethod("someMethodName", .....)
) cada vez que cambie el nombre de ese método, como durante un refactorizador, lo hará Es necesario recordar actualizar los parámetros al método de reflexión para que coincida con la nueva firma del método, o la llamada getDeclaredMethod
generará una NoSuchMethodException
.
Si este es el motivo, entonces el seguimiento de la pila debe mostrar el punto en que se invoca el método de reflexión, y solo deberá actualizar los parámetros para que coincidan con la firma del método real.
En mi experiencia, esto aparece ocasionalmente cuando la unidad prueba métodos / campos privados, y usa una clase TestUtilities
para extraer campos para la verificación de pruebas. (Generalmente con código heredado que no se diseñó teniendo en cuenta las pruebas unitarias).
Estos problemas son causados por el uso del mismo objeto en las mismas dos clases. Los objetos usados no contienen un nuevo método 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)
He tenido el mismo problema. Esto también se produce cuando hay una ambigüedad en las clases. Mi programa intentaba invocar un método que estaba presente en dos archivos JAR presentes en la misma ruta de ubicación / clase. Elimine un archivo JAR o ejecute su código de modo que solo se use un archivo JAR. Compruebe que no está utilizando el mismo JAR o versiones diferentes del mismo JAR que contienen la misma clase.
DISP_E_EXCEPTION [step] [] [Z-JAVA-105 excepción de Java java.lang.NoSuchMethodError (com.example.yourmethod)]
La respuesta anterior explica muy bien ... solo para agregar una cosa. Si está usando el eclipse, use ctrl + shift + T e ingrese la estructura del paquete de la clase (por ejemplo: gateway.smpp.PDUEventListener), encontrará todos los jar / proyectos donde está presente . Elimine jarras innecesarias de classpath o agregue arriba en classpath. Ahora recogerá la correcta.
Me encontré con un problema similar cuando estaba cambiando las firmas de métodos en mi aplicación. La limpieza y reconstrucción de mi proyecto resolvió el "NoSuchMethodError".
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.
-
Employee.java
-> Contiene la variable (EmpId
) cuyo tipo de datos ha cambiado deint
aString
. -
ReportGeneration.java
-> Recupera el valor usando el getter,getEmpId()
.
Se supone que debemos volver a unir el contenedor incluyendo solo las clases modificadas. Como no hubo cambios en ReportGeneration.java
, solo ReportGeneration.java
Employee.class
en el archivo Jar. Tuve que incluir el archivo ReportGeneration.class
en el ReportGeneration.class
para resolver el problema.
Me he encontrado con este error también.
Mi problema es que he cambiado la firma de un método, algo así como
void invest(Currency money){...}
dentro
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 guardó silencio con respecto a las 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 al método, que contiene el método main ().
Este problema no es algo que pueda encontrar con demasiada frecuencia, ya que con mayor frecuencia el proyecto se reconstruye manualmente o una acción de compilación se desencadena automáticamente, en lugar de simplemente compilar la clase modificada.
Mi caso de uso fue que genere un archivo .jar que se iba a utilizar como una revisión, que no contenía la App.class, ya que no se modificó. Tenía sentido para mí no incluirlo ya que mantuve la herencia base de la clase base del argumento inicial.
El asunto es que cuando compila una clase, el bytecode resultante es algo estático , en otras palabras, es una referencia difícil .
El bytecode original desmontado (generado con la herramienta javap) se ve así:
#7 = Methodref #2.#22 // Bank.invest:(LCurrency;)V
Después de que el cargador de clases cargue el nuevo compilado Bank.class, no encontrará dicho método, aparecerá como si se hubiera eliminado y no se hubiera modificado, por lo tanto, el error mencionado.
Espero que esto ayude.
Para mí sucedió porque cambié el tipo de argumento en la función, desde el Objeto a, a la Cadena a. Podría resolverlo con limpieza y construir de nuevo
Para responder la pregunta original. De acuerdo con los documentos de Java here :
"NoSuchMethodError" Lanzado si una aplicación intenta llamar a un método específico de una clase (ya sea estática o instancia), y esa clase ya no tiene una definición de ese método.
Normalmente, este error es capturado por el compilador; este error solo puede ocurrir en tiempo de ejecución si la definición de una clase ha cambiado de manera incompatible.
- Si ocurre en el tiempo de ejecución, verifique que la clase que contiene el método esté en la ruta de la clase.
- Compruebe si ha agregado una nueva versión de JAR y el método es compatible.
Pruebe de esta manera: elimine todos los archivos .class en sus directorios de proyectos (y, por supuesto, todos los subdirectorios). Reconstruir.
A veces mvn clean
(si está usando maven) no limpia archivos .class creados manualmente por javac
. Y esos archivos antiguos contienen firmas antiguas, lo que lleva a NoSuchMethodError
.
Si está escribiendo una aplicación web, asegúrese de no tener versiones conflictivas de un contenedor en el directorio de la biblioteca global de su contenedor y también en su aplicación. Es posible que no necesariamente sepa qué jar está utilizando el cargador de clases.
p.ej
- tomcat / common / lib
- mywebapp / WEB-INF / lib
Si su nombre de archivo es diferente al nombre de la clase que contiene el método principal, entonces puede ser la posibilidad de que este error pueda causar.
Si tiene acceso para cambiar los parámetros de JVM, agregar resultados detallados 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 debe volcar a la información de salida estándar, como por ejemplo:
...
[Loaded junit.framework.Assert from file: / C: /Program%20Files/junit3.8.2/junit.jar]
...
Si usas maven u otro framework, y obtienes este error casi al azar, prueba con "limpiar instalación", especialmente si escribiste el objeto y sabes que tiene el método. Trabajó para mi.
Siento tu dolor. Puedes aprender programación de un libro, pero cuando se trata de trabajar con Eclipse o Visual Studio, es una pesadilla hacer algo simple como agregar una biblioteca. Todo el mundo espera que sepas cómo usarlo y si no lo haces rechazan tu pregunta. El problema es que si no trabajas en una oficina o conoces a alguien a quien le puedes hacer estas preguntas, entonces es casi imposible entender esto. De todas formas...
Estaba teniendo tu problema, y así es como lo solucioné. Los siguientes pasos son una forma efectiva de agregar una biblioteca. Había hecho los dos primeros pasos correctos, pero no había hecho el último arrastrando el archivo ".jar" directamente desde el sistema de archivos a la carpeta "lib" en mi proyecto de 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".
Si alguien sabe de una manera más adecuada de agregar / actualizar una biblioteca, por favor repita.
Paso 1 - Agregue .jar para compilar la ruta
Paso 2 - Fuentes asociadas y javadocs (opcional)
Paso 3 - Arrastre en realidad el archivo .jar en la carpeta "lib" (no opcional)
Significa que el método respectivo no está presente en la clase:
- Si está usando jar, descompile y verifique si la versión respectiva de jar tiene la clase adecuada.
- Compruebe si ha compilado la clase adecuada de su fuente.
Sin más información, es difícil identificar el problema, pero la causa principal es que lo más probable es que haya compilado una clase con una versión diferente de la clase que le falta un método, que la que está utilizando al ejecutarla.
Observe el seguimiento de la pila ... Si aparece la excepción al invocar un método en un objeto en una biblioteca, lo más probable es que utilice versiones separadas de la biblioteca al compilar y ejecutar. Asegúrate de tener la versión correcta en ambos lugares.
Si aparece la excepción al invocar un método en objetos instanciados por clases creadas, entonces su proceso de compilación parece estar defectuoso. Asegúrese de que los archivos de clase que está ejecutando realmente se actualicen al compilar.
Tenga en cuenta que en el caso de la reflexión, obtiene una NoSuchMethodException
, mientras que con el código no reflectivo, obtiene NoSuchMethodError
. Tiendo a buscar en lugares muy diferentes cuando me enfrento a uno contra el otro.