Java.lang.VerifyError: waiting for a stack frame in the target JDK 1.7 branch

Question

After upgrading to JDK 1.7, I get below exceptions:

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) 

Answer 1

In Java 7, stricter verification was introduced and the format of the bit class was changed to contain the stack map used to verify the correctness of the code. The exception you see means that some method does not have a valid stack map.

One could blame the Java version or bytecode. This usually means that the library used by the application generates invalid bytecode that does not pass a more rigorous check. Therefore, nothing more than a message about this as an error in the library can be made by the developer.

As a workaround, you can add -noverify to the JVM arguments to disable validation. In Java 7, you could also use -XX:-UseSplitVerifier to use a less stringent check, but this option has been removed in Java 8.

Answer 2

If you are using java 1.8, remove XX:-UseSplitVerifier and use -noverify in your JVM properties.

Answer 3

I ran into this problem and try to use the -noverify flag, which really works. This is due to the new bytecode verifier. So the flag should really work. I am using JDK 1.7.

Note. This will not work if you are using JDK 1.8

Answer 4

The only difference between the files that cause the problem is the 8th byte of the file

CA FE BA BE 00 00 00 33 - Java 7

against.

CA FE BA BE 00 00 00 32 - Java 6

Setting -XX:-UseSplitVerifier fixes the problem. However, the cause of this problem is https://bugs.eclipse.org/bugs/show_bug.cgi?id=339388

Answer 5

Pass the JVM -noverify argument to the test task. If you use gradle, in build.gradle you can have something like:

 test { jvmArgs "-noverify" } 

Answer 6

Sorry for digging, but I met the same problem and found a simpler solution.

In the Java compiler settings, you need to uncheck the box "Save unused (never read) local variables" , so there is no need to change the target version of the JVM back.

This seems to be a bug in older versions of Eclipe.

Answer 7

If you write the code yourself, this problem can be overcome by providing the jQuery compiler "-target 1.5" (or by setting the appropriate parameter in your IDE or your build configuration).

Answer 8

This link is helpful. java.lang.VerifyError: wait for stack frame

The easiest way is to change the JRE to 6.