has - java error java lang nosuchmethoderror

Java "NoSuchMethodError"

Question

Me estoy poniendo:

NoSuchMethodError: com.foo.SomeService.doSmth()Z

¿Comprendo correctamente que esta ''Z'' significa que el tipo de retorno del método doSmth () es booleano? Si es verdadero, entonces ese tipo de método realmente no existe porque este método devuelve algo de Colección. Pero por otro lado, si llamo a este método, no estoy asignando su valor de retorno a ninguna variable. Acabo de llamar a este método así:

service.doSmth();

¿Alguna idea de por qué se produce este error? Todos los archivos JAR necesarios existen y todos los otros métodos de esta clase parecen existir.

Answer 1

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.

En resumen, un archivo de clase / jar en tiempo de ejecución no es lo mismo que usó en tiempo de compilación.

Answer 2

Esta es probablemente una diferencia entre su classpath en tiempo de compilación y su classpath en tiempo de ejecución.

Esto es lo que parece estar pasando:

• El código se compila con una ruta de clase que define el método doSmth() que devuelve un valor booleano. El código de bytes se refiere al método doSmth()Z
• En tiempo de ejecución, el doSmth()Z no se encuentra. En su lugar, se encuentra un método que devuelve una Colección.

Para corregir este problema, compruebe su classpath (tiempo de compilación).

Answer 3

La respuesta actual solo te dice por qué está fallando. Por lo general, es incluso mejor saber cómo solucionar problemas. Como se menciona, el problema generalmente es que usted creó su programa, pero cuando lo ejecuta o lo exporta, la biblioteca no está incluida. Así que la solución es ...

Si está ejecutando, verifique la pestaña Ejecutar Ejecutar configuración -> Ejecutar configuraciones -> Seleccione la configuración que está ejecutando -> Revisar la pestaña Classpath -> Asegúrese de que las bibliotecas que necesita estén allí

Si está exportando (por ejemplo, un archivo war), siga este Seleccione el proyecto -> Seleccione las propiedades -> Seleccione el conjunto de implementación -> Presione Agregar -> Seleccione las entradas de la ruta de compilación de Java -> Seleccione las bibliotecas que desea incluir en su archivo exportado (por ejemplo un archivo de guerra)

En ambos casos, asegúrese de incluir la biblioteca a la que hace referencia.

Otros problemas frecuentes de este error no son el tipo correcto de parámetros o visibilidad, pero luego, el compilador detectará el error antes de ejecutarse. En este caso, solo verifique la documentación para que coincida con la función y la visibilidad del paquete, y asegúrese de que la biblioteca se encuentre en Java Build Path en las propiedades de su proyecto.

Answer 4

Noté que este problema ocurría al probar algunos cambios experimentales en múltiples proyectos vinculados, después de actualizarlos desde SVN en Eclipse.

Específicamente, actualicé todos los proyectos de SVN y revertí el archivo .classpath en lugar de editarlo manualmente para mantener las cosas simples.

Luego volví a agregar los proyectos vinculados a la ruta, pero olvidé eliminar los archivos jar relacionados. Así fue como se me ocurrió el problema.

Aparentemente, el tiempo de ejecución usó el archivo jar mientras que el compilador usó los archivos del proyecto.

Answer 5

Otra forma en que esto puede suceder y es difícil de encontrar:

Si la firma de un método en un jar externo cambia de una manera que no se encuentra ningún error en el IDE porque aún es compatible con la forma en que lo llamas, la clase podría no volver a compilarse.

Si su compilación comprueba los archivos en busca de cambios y solo los recompila, la clase podría no ser compilada durante el proceso de compilación.

Así que cuando lo ejecutas, esto podría llevar a ese problema. Aunque tiene el nuevo tarro, su propio código espera aún el anterior pero nunca se queja.

Para hacerlo más difícil, depende de la JVM si puede manejar tales casos. Entonces, en el peor de los casos, se ejecuta en el servidor de prueba pero no en la máquina en vivo.

Answer 6

Parece que el método existe en classpath durante la compilación, pero no durante la ejecución de su aplicación.

No creo que el tipo de retorno sea un problema. Si lo fuera, no compilaría. El compilador arroja un error cuando la llamada al método es ambigua, y es cuando dos métodos difieren solo por el tipo de retorno.

Answer 7

Quizás aún pueda ayudar a alguien, pero esta excepción también puede ocurrir cuando tiene en la ruta de clase dos clases en diferentes archivos jar que tienen la misma firma exacta pero no tienen los mismos métodos públicos.

Por ejemplo:

• En el archivo mylibrary1.jar tienes la clase com.mypackage.mysubpackage.MyClass con el método doSmth ()

• En el archivo mylibrary2.jar tienes la clase com.mypackage.mysubpackage.MyClass sin el método doSmth ()

Al buscar en la clase, el cargador de clases puede encontrar primero mylibrary2.jar dependiendo de la prioridad de la ruta, pero no puede encontrar el método en esa clase.

Asegúrate de no tener el mismo paquete + clase en dos archivos diferentes.