java.lang.VerifyError: Attente d'un cadre stackmap au niveau de la cible de branche JDK 1.7

88

Après la mise à niveau vers JDK 1.7, je reçois l'exception ci-dessous:

java.lang.VerifyError: Expecting a stackmap frame at branch target 71 in method com.abc.domain.myPackage.MyClass$JaxbAccessorM_getDescription_setDescription_java_lang_String.get(Ljava/lang/Object;)Ljava/lang/Object; at offset 20
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2413)
    at java.lang.Class.getConstructor0(Class.java:2723)
    at java.lang.Class.newInstance0(Class.java:345)
    at java.lang.Class.newInstance(Class.java:327)
    at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:184)
    at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:129)
    at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$GetterSetterReflection.optimize(Accessor.java:384)
    at com.sun.xml.internal.bind.v2.runtime.property.SingleElementLeafProperty.<init>(SingleElementLeafProperty.java:72)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
    at com.sun.xml.internal.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:113)
    at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:166)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:494)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:311)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:126)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1148)
    at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:130)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:248)
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:235)
    at javax.xml.bind.ContextFinder.find(ContextFinder.java:445)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:637)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584)
    at com.abc.domain.myPackage.MyClass.marshalFacetsTest(MyClass.java:73)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
    at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
    at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
    at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
    at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:128)
    at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
    at org.testng.TestRunner.privateRun(TestRunner.java:767)
    at org.testng.TestRunner.run(TestRunner.java:617)
    at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
    at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
    at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
    at org.testng.SuiteRunner.run(SuiteRunner.java:240)
    at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
    at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
    at org.testng.TestNG.runSuitesSequentially(TestNG.java:1203)
    at org.testng.TestNG.runSuitesLocally(TestNG.java:1128)
    at org.testng.TestNG.run(TestNG.java:1036)
    at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
    at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
    at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
java  jaxb  java-7 
— John
source

Réponses:

171

Java 7 a introduit une vérification plus stricte et a légèrement modifié le format de la classe - pour contenir une carte de pile utilisée pour vérifier que le code est correct. L'exception que vous voyez signifie que certaines méthodes n'ont pas de carte de pile valide.

La version Java ou l'instrumentation bytecode pourraient être toutes deux à blâmer. Cela signifie généralement qu'une bibliothèque utilisée par l'application génère un bytecode non valide qui ne passe pas la vérification plus stricte. Donc, rien d'autre que de le signaler comme un bogue à la bibliothèque ne peut être fait par le développeur.

Pour contourner le problème, vous pouvez ajouter -noverifydes arguments JVM afin de désactiver la vérification. Dans Java 7, il était également possible d'utiliser -XX:-UseSplitVerifierla méthode de vérification la moins stricte, mais cette option a été supprimée dans Java 8.

— Mirko Adari
source
1
Mais que signifie -XX: -UseSplitVerifier ?? J'ai regardé l'explication d'Oracle, elle dit: "Utilisez le nouveau vérificateur de type avec les attributs StackMapTable". Je n'ai pas compris.
— John
2
Donc, si je vois ces erreurs: s'agit-il d'un bogue dans la JVM ou dans mon code?
— bentolor
4
cette réponse n'est pas valable à long terme, ou peut-être plus déjà, car Oracle abandonne cette option. Je suis affligé par ce bogue (avec un autre code) et je cherche un moyen de reconstruire avant de reconstruire les stackmaps
— ZiglioUK
2
pour le test unitaire, vous devez passer les arguments dans le plugin surefire. Cela a résolu le problème pour les compilateurs java 7 et 8: <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-surefire-plugin </artifactId> <version> 2.18.1 </ version > <configuration> <argLine> -noverify -XX: -UseSplitVerifier </argLine> </configuration> </plugin>
— Antoine Wils
2
J'étais confronté au même problème mais après avoir ajouté -noverify, cela a vraiment fonctionné pour moi.Merci.
— Praveen Kumar Mekala
15

Si vous utilisez java 1.8, supprimez XX:-UseSplitVerifieret utilisez -noverifydans vos propriétés JVM.

— Anand Kumar KK
source
8

J'ai rencontré ce problème et j'ai essayé d'utiliser le drapeau -noverifyqui fonctionne vraiment. C'est à cause du nouveau vérificateur de bytecode. Le drapeau devrait donc vraiment fonctionner. J'utilise JDK 1.7.

Remarque: cela ne fonctionnera pas si vous utilisez JDK 1.8

— Charan Raj
source
3
Pour moi, l'utilisation de l'indicateur a été corrigée en exécutant nos tests unitaires Android en utilisant JRE 8 comme runtime.
— ubuntudroid
2
-noverify a également fonctionné pour moi sur Java 8. J'utilise gradle pour Android et j'ai donc dû mettre l'indicateur -noverify à l'endroit spécifié dans stackoverflow.com/a/37593189/2848676
— Michael Osofsky
où avez-vous mis -noverify? Je l'ai défini comme MAVEN_OPTS mais cela ne fonctionne pas pour moi
— dev
@Sara Antunez, Dans le fichier build.gradle de vos modules d'application dans la fermeture Android, ajoutez ceci. android {.... testOptions {unitTests.all {jvmArgs '-noverify'}}}
— GrokkingDroid
2

Passer -noverifyargument JVM à votre tâche de test. Si vous utilisez gradle, build.gradlevous pouvez avoir quelque chose comme:

test {
  jvmArgs "-noverify"
}
— Leo
source
0

Cette ERREUR peut se produire lorsque vous utilisez Mockito pour simuler les classes finales .

Pensez à utiliser Mockito inline ou Powermock à la place.

— nhoxbypass
source
-1

Désolé d'avoir creusé, mais j'ai rencontré le même problème et j'ai trouvé la solution la plus simple.

Dans les options du compilateur Java, vous devez décocher "Conserver les variables locales inutilisées (jamais lues)" afin qu'il n'y ait pas besoin de modifier la version JVM cible.

Cela semble être un bogue dans les anciennes versions d'Eclipe.

— Scoro
source
ça ne marche pas pour moi. Voici l'essentiel de mon erreur: gist.github.com/ZiglioNZ/bd1d7d424727b3f26c64
— ZiglioUK
3
L'OP ne mentionne pas Eclipse. Il ne l'utilise peut-être même pas.
— Don Branson
-3

Si vous construisez le code vous-même, alors ce problème peut être résolu en donnant "-target 1.5" au compilateur java (ou en définissant l'option correspondante dans votre IDE ou votre configuration de construction).

— jrajp2184
source
-11

ce lien est utile. java.lang.VerifyError: Attente d'un cadre de stackmap

le moyen le plus simple est de changer JRE en 6.

— yuxiaomin
source
7
rétrograder quand un simple argument JVM peut réparer? Je doute de votre définition de simple.
— Visionary Software Solutions
1
Bien que cela puisse théoriquement répondre à la question, il serait préférable d'inclure ici les parties essentielles de la réponse et de fournir le lien pour référence.
— Joachim Sauer
C'est un travail autour. Comme l'a dit Joachim, cela peut fonctionner - mais cela ne définit pas le problème ou l'aide pour les équipes ou les bases de code qui doivent utiliser Java 7
— Crowie
Il y a plusieurs réponses dans la question liée. Le déclassement n'est qu'une option répertoriée.
— Ogre Psalm33
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.