it-swarm.com.de

java.lang.VerifyError: Erwartet einen Stackmap-Frame am Verzweigungsziel-JDK 1.7

Nach dem Upgrade auf JDK 1.7 erhalte ich eine Ausnahme:

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)
78
John

Java 7 führte eine strengere Überprüfung ein und änderte das Klassenformat etwas, um eine Stack-Map zu enthalten, die zur Überprüfung der Richtigkeit des Codes dient. Die angezeigte Ausnahme bedeutet, dass für eine Methode keine gültige Stapelzuordnung vorhanden ist. 

Schuld daran könnten sowohl die Java-Version als auch die Bytecode-Instrumentierung sein. Normalerweise bedeutet dies, dass eine von der Anwendung verwendete Bibliothek einen ungültigen Bytecode generiert, der die strengere Überprüfung nicht besteht. Der Entwickler kann also nichts anderes tun, als ihn als Fehler an die Bibliothek zu melden.

Als Problemumgehung können Sie den JVM-Argumenten -noverify hinzufügen, um die Überprüfung zu deaktivieren. In Java 7 war es auch möglich, -XX:-UseSplitVerifier zur Verwendung der weniger strengen Überprüfungsmethode zu verwenden, diese Option wurde jedoch in Java 8 entfernt.

156
Mirko Adari

Wenn Sie Java 1.8 verwenden, entfernen Sie XX:-UseSplitVerifier und verwenden Sie -noverify in Ihren JVM-Eigenschaften. 

13
Anand Kumar K K

Ich bin auf dieses Problem gestoßen und versuche das Flag -noverify zu verwenden, das wirklich funktioniert. Dies liegt an dem neuen Bytecode-Verifizierer. Die Flagge sollte also wirklich funktionieren .. Ich benutze JDK 1.7. 

Hinweis: Dies funktioniert nicht, wenn Sie JDK 1.8 verwenden

8
Charan Raj

Der einzige Unterschied zwischen den Dateien, die das Problem verursachen, ist das 8. Byte der Datei

CA FE BA BE 00 00 00 33 - Java 7

vs.

CA FE BA BE 00 00 00 32 - Java 6

Durch die Einstellung von -XX:-UseSplitVerifier wird das Problem behoben. Die Ursache für dieses Problem ist jedoch https://bugs.Eclipse.org/bugs/show_bug.cgi?id=339388

2
A Kunin

Übergeben Sie das -noverify-JVM-Argument an Ihre Testaufgabe. Wenn Sie Gradle verwenden, können Sie in build.gradle Folgendes eingeben:

test {
  jvmArgs "-noverify"
}
1
Leo

Tut mir leid, aber ich habe das gleiche Problem gefunden und die einfachere Lösung gefunden.

In den Java-Compiler-Optionen müssen Sie die Markierung von "Nicht verwendete (niemals gelesene) lokale Variablen beibehalten" deaktivieren, damit die JVM-Zielversion nicht geändert werden muss. 

Es scheint ein Fehler in einer älteren Eclipe-Version zu sein.

0
scoro