Raisons d’obtenir un java.lang.VerifyError

Question

Je recherche la suite de java.lang.Exception verifyerror

java.lang.VerifyError: (class: be/post/ehr/wfm/application/serviceorganization/report/DisplayReportServlet, method: getMonthData signature: (IILjava/util/Collection;Ljava/util/Collection;Ljava/util/HashMap;Ljava/util/Collection;Ljava/util/Locale;Lorg/apache/struts/util/MessageRe˜̴MtÌ´MÚw€mçw€mp:Â"MŒŒ
                at java.lang.Class.getDeclaredConstructors0(Native Method)
                at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
                at java.lang.Class.getConstructor0(Class.java:2671)

Il se produit lorsque le serveur jboss dans lequel la servlet est déployé est commencé. Il est compilé avec jdk-1.5.0_11 et j'ai essayé de recompiler avec jdk-1.5.0_15 sans succès. C'est la compilation se passe bien, mais lorsqu'il est déployé, le java.lang.Exception verifyerror se produit.

Quand j'ai changé le methodname et j'ai obtenu le message d'erreur suivant:

java.lang.VerifyError: (class: be/post/ehr/wfm/application/serviceorganization/r    eport/DisplayReportServlet, method: getMD signature: (IILjava/util/Collection;Lj    ava/util/Collection;Ljava/util/HashMap;Ljava/util/Collection;Ljava/util/Locale;L    org/apache/struts/util/MessageResources ØÅN|ØÅNÚw€mçw€mX#ÖM|XÔM
            at java.lang.Class.getDeclaredConstructors0(Native Method)
            at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357
            at java.lang.Class.getConstructor0(Class.java:2671)
            at java.lang.Class.newInstance0(Class.java:321)
            at java.lang.Class.newInstance(Class.java:303)

Vous pouvez voir que plus de la signature de la méthode est illustré.

La véritable signature de la méthode est

  private PgasePdfTable getMonthData(int month, int year, Collection dayTypes,
                          Collection calendarDays,
                          HashMap bcSpecialDays,
                          Collection activityPeriods,
                          Locale locale, MessageResources resources) throws   Exception {

J'ai déjà essayé de regarder avec javap et qui donne à la signature de la méthode comme il se doit.

Lors de mes autres collègues de vérifier le code, le compiler et de le déployer, ils ont le même problème. Lorsque le serveur de build prend le code et le déploie sur le développement ou d'environnements de tests (hp-ux), la même erreur se produit. Aussi un système automatisé de machine d'essai d'ubuntu affiche le même message d'erreur lors du démarrage du serveur.

Le reste de l'application fonctionne ok, seulement qu'un servlet est hors d'ordre. Toute idée où chercher, ce serait utile.

Answer 1

java.lang.VerifyError peut être le résultat si vous avez compilé à l'encontre d'une autre bibliothèque que vous utilisez au moment de l'exécution.

Par exemple, ce qui m'est arrivé lorsque vous essayez d'exécuter un programme qui a été compilé avec Xerces 1, mais Xerces 2 a été trouvé sur le chemin de la classe. Les classes nécessaires (en org.apache.* d'espace de noms) ont été trouvés au moment de l'exécution, de sorte ClassNotFoundException était pas le résultat. Il y a eu des changements sur les classes et les méthodes, ainsi que les signatures de méthode trouvé lors de l'exécution ne correspond pas à ce qui était là au moment de la compilation.

Normalement, le compilateur signalera les problèmes où la méthode signatures ne correspondent pas. La JVM va vérifier le bytecode de nouveau lorsque la classe est chargée, et le jette VerifyError lorsque le bytecode est en train de faire quelque chose qui ne devrait pas être autorisée, par exemple, l'appel d'une méthode qui retourne String , puis stocke cette valeur dans un champ qui est titulaire d'un List.

Answer 2

java.lang.VerifyError sont les pires.

Vous obtiendrez cette erreur si la taille du bytecode de votre méthode dépasse la limite de 64 Ko; mais vous auriez probablement remarqué cela.

Êtes-vous sûr à 100% que cette classe n'est pas présente dans le classpath ailleurs dans votre application, peut-être dans un autre pot?

De plus, à partir de votre stacktrace, le codage de caractères du fichier source (utf-8?) Est-il correct?

Answer 3

Comme l'a dit Kevin Panko, c'est principalement à cause du changement de bibliothèque. Donc, dans certains cas, un "nettoyage" du projet (répertoire) suivi d'une construction fait l'affaire.

Answer 4

Une chose que vous pouvez essayer est d'utiliser -Xverify: tout ce qui va vérifier bytecode sur le chargement et donne parfois des messages d'erreur utiles si le bytecode est invalide.

Answer 5

J’ai corrigé cette erreur sur Android en faisant le projet j’étais importation d’une bibliothèque, telle que décrite ici http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject

Auparavant, j’étais juste référençant le projet (ne pas ce qui en fait une bibliothèque), et je recevais cette étrange VerifyError.

Espérons que cela aide quelqu'un.