java.lang.VerifyError: Expecting a stackmap frame at branch target JDK 1.7

Question

After upgrading to JDK 1.7 I am getting below exception:

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)

Dutch

Answer 1

Java 7 introduced stricter verification and changed the class format a bit—to contain a stack map used to verify that code is correct. The exception you see means that some method doesn't have a valid stack map.

Java version or bytecode instrumentation could both be to blame. Usually this means that a library used by the application generates invalid bytecode that doesn't pass the stricter verification. So nothing else than reporting it as a bug to the library can be done by the developer.

As a workaround you can add -noverify to the JVM arguments in order to disable verification. In Java 7 it was also possible to use -XX:-UseSplitVerifier to use the less strict verification method, but that option was removed in Java 8.

Frequency

But what does -XX:-UseSplitVerifier mean?? I looked at oracle's explaination,It says "Use the new type checker with StackMapTable attributes". I didn't get it. – Dutch

So if I see this errors: Is this a bug within the JVM or my code? – Phene

this answer is not valid in the long terms, or perhaps any longer already, as Oracle is deprecating this option. I'm afflicted by this bug (with other code) and am looking for a way to fore rebuild of stackmaps – Finegrain

Does anyone has an idea about what if the same situation but runs on a linux machine? I got the error that "-XX:-UseSplitVerifier: command not found". – Ockham

After using UseSplitVerifier and noverify options, the byte code validation error goes away. But then I get a new error: NoClassDefFoundError. I am using jdk1.7.0_76 on OS X 10.10.3. – Glissade

for unit test you have to pass the arguments in the surefire plugin. This fixed the issue for both java 7 and 8 compilers:<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> – Insolvent

I've had exactly the same issue on Java 1.8, and the option -noverify did the work. Is there anything better to fix it? – Ablution

i was facing the same issue but after adding -noverify it really worked for me.Thanks. – Trilobate

-noverify also worked for me. I'm using gradle for Android and so I had to put the -noverify flag where specified in https://mcmap.net/q/245819/-jvm-options-in-android-when-run-gradlew-test – Shutter

Answer 2

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

Chagrin

Answer 3

I ran into this problem and try using the flag -noverify which really works. It is because of the new bytecode verifier. So the flag should really work. I am using JDK 1.7.

Note: This would not work if you are using JDK 1.8

Viewless

For me using the flag fixed executing our Android Unit Tests using JRE 8 as a runtime. – Marja

-noverify also worked for me on Java 8. I'm using gradle for Android and so I had to put the -noverify flag where specified in https://mcmap.net/q/245819/-jvm-options-in-android-when-run-gradlew-test – Shutter

where did you set -noverify? I set it as MAVEN_OPTS but its not working for me – Sommerville

@Sara Antunez, In your application modules' build.gradle file in android closure, add this. android { .... testOptions { unitTests.all { jvmArgs '-noverify' } } } – Serajevo

Answer 4

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

test {
  jvmArgs "-noverify"
}

Ruthenic

Answer 5

The only difference between files that causing the issue is the 8th byte of file

CA FE BA BE 00 00 00 33 - Java 7

vs.

CA FE BA BE 00 00 00 32 - Java 6

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

Stet

Answer 6

This ERROR can happen when you use Mockito to mock final classes.

Consider using Mockito inline or Powermock instead.

Spatula

Answer 7

I had a similar issue that was caused by the -preverify flag. Removing that flag fixed the issue for me. JVM 1.7+ is incompatible with that option. https://www.guardsquare.com/manual/configuration/usage#dontpreverify

Cadell

Answer 8

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

In Java compiler options you need to uncheck "Preserve unused (never read) local variables" so there is no need to change back target JVM version.

It seems to be a bug in an older Eclipe versions.

Phototypography

it doesn't work for me. Here's a gist of my error: gist.github.com/ZiglioNZ/bd1d7d424727b3f26c64 – Finegrain

The OP doesn't mention Eclipse. He may not even be using it. – Thrift

Answer 9

If you are building the code yourself, then this issue could be overcome by giving "-target 1.5" to the java compiler (or by setting the corresponding option in your IDE or your build config).

Dniren

Answer 10

this link is helpful. java.lang.VerifyError: Expecting a stackmap frame

the simplest way is changing JRE to 6.

Bilow

downgrading when a simple JVM arg can fix? I doubt your definition of simple. – Strangulate

Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – Detinue

This is a work around. As Joachim said, it may work - but it doesn't define the problem or help for teams or code bases that must use Java 7 – Rewarding

There are multiple answers in the linked question. Downgrading is only one listed option. – Craigcraighead