Jacoco Plugin fails with VerifyError

Old Forum
1

I have a sample project here: https://dl.dropboxusercontent.com/u/9582863/JacocoTest.tgz . It consists of simple class and a test. If I run this project with

gradlew test
  :test
  Gradle test > eu.plumbr.aClassTest.main FAILED
    java.lang.VerifyError at aClassTest.java:9
  1 test completed, 1 failed
:test FAILED

java.lang.VerifyError: Bad local variable type in method eu.plumbr.aClass.findCustomerReportById(J)Ljava/lang/Long; at offset 94
 at eu.plumbr.aClassTest.main(aClassTest.java:9)

If I run it with provided Ant build.xml via Jacoco own ant tasks, then everything runs just fine.

2

It is likely a stackmap frame related bug of the byte code instrumentor.

You can workaround the issue with:

test {

jvmArgs ‘-XX:-UseSplitVerifier’

}

3

It works, thanks!

4

Disabling the split verifier won’t work as soon as you need to use Java 7 language features…

5

Which feature does not work with the old verifier? As far as I know, the only new byte code instruction is invokedynamic but it is not used by javac (in Java7). Is there anything I missing?

6

Which feature does not work with the old verifier? As far as I know, the only new byte code instruction is invokedynamic but it is not used by javac (in Java7). Is there anything I missing?

7

Java 7 uses a new class file version (51). The split verifier is needed to verify files using the new format, even if they don’t use the invokedynamic instruction. Similarly, any java code compiled using -source 1.7 -target 1.7 uses the new class file format.

So even to use the diamond syntax, you need to compile in 1.7 mode, which means that you need to use the split verifier.

See these links: https://weblogs.java.net/blog/fabriziogiudici/archive/2012/05/07/understanding-subtle-new-behaviours-jdk-7 http://www.oracle.com/technetwork/java/javase/compatibility-417013.html

for more information.

8

The class file format is one thing, it shouldn’t affect (in itself) the verifier. Actually, I have just tried -XX:-UseSplitVerifier with a code heavily relying on Java7 features (API and syntax) and it works well. I haven’t tried it with a byte code which uses invokedynamic though.

9

This still happens with groovy code and gradle 2.1 which has a version of jacoco that claims to use asm 5 and be compatible with Java 8.

With regressions like https://bugs.openjdk.java.net/browse/JDK-8051012 I guess you just need to give up on the Java maintainers if you want to use groovy.