web-dev-qa-db-fra.com

java.lang.VerifyError: attente d'un cadre de pile dans le branche JDK 1.7

Après la mise à niveau vers JDK 1.7, je reçois une 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)
javajaxbjava-7
78
John

Java 7 a introduit une vérification plus stricte et a légèrement modifié le format de la classe afin de contenir une mappe de pile permettant de vérifier que le code est correct. L'exception que vous voyez signifie qu'une méthode n'a pas de mappage de pile valide. 

La version Java ou l’instrumentation en bytecode pourraient être toutes deux responsables. 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 la plus stricte. Donc, rien d'autre que le signaler comme un bogue à la bibliothèque peut être fait par le développeur.

Pour contourner le problème, vous pouvez ajouter -noverify aux arguments de la machine virtuelle Java afin de désactiver la vérification. En Java 7, il était également possible d'utiliser -XX:-UseSplitVerifier pour utiliser la méthode de vérification moins stricte, mais cette option a été supprimée en Java 8.

156
Mirko Adari

Si vous utilisez Java 1.8, supprimez XX:-UseSplitVerifier et utilisez -noverify dans vos propriétés JVM. 

13
Anand Kumar K K

J'ai rencontré ce problème et j'essaie d'utiliser le drapeau -noverify qui fonctionne vraiment. C'est à cause du nouveau vérificateur de bytecode. Donc, le drapeau devrait vraiment fonctionner ... J'utilise JDK 1.7. 

Remarque: cela ne fonctionnerait pas si vous utilisez JDK 1.8.

8
Charan Raj

La seule différence entre les fichiers à l'origine du problème est le 8ème octet du fichier.

CA FE BA BE 00 00 00 33 - Java 7

vs.

CA FE BA BE 00 00 00 32 - Java 6

Le réglage de -XX:-UseSplitVerifier résout le problème. Cependant, la cause de ce problème est https://bugs.Eclipse.org/bugs/show_bug.cgi?id=339388

2
A Kunin

Passez l'argument -noverify JVM à votre tâche de test. Si vous utilisez gradle, dans le build.gradle vous pouvez avoir quelque chose comme:

test {
  jvmArgs "-noverify"
}
1
Leo

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

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

Cela semble être un bogue dans une ancienne version d'Eclipe.

0
scoro