Testng、Emma、Cobertura、覆盖率和 JDK 7 导致 ClassFormatError 和VerifyError
我已经切换到最新的 JDK 7,并且在使用 emma 覆盖工具处理的字节码上运行 testng 单元测试时遇到问题。我的测试用例都没有正确运行,并且对于大多数测试用例,我都收到了此类错误。
java.lang.ClassFormatError: Illegal local variable table length 10 in method measurement.meter.AbstractSerialPortMeter.<init>(Lmeasurement/meter/SerialPort;)V at measurement.meter.Elc3133aTest.setUp(Elc3133aTest.java:42)
我在这里找到一篇文章 JSR 292 Goodness 快速代码覆盖工具 不到 10k, 也就是说,“JSR 292 引入了新的字节码指令 invokedynamic,而且还引入了几种新的常量池常量。这意味着大多数解析字节码的工具(如 ASM、BCEL、findbugs 或 EMMA)需要更新为 java 7兼容的。”
查看了Emma的主页,好像已经很久没有更新了。
有人解决过类似的问题吗?
我也尝试过Cobertura。它看起来工作得更好一些,但我收到了很多 VerifyError
类型的异常。
java.lang.VerifyError: Expecting a stackmap frame at branch target 85 in method measurement.meter.AbstractSerialPortMeter.close()V at offset 26
at measurement.meter.AbstractSerialPortMeterTest.setUp(AbstractSerialPortMeterTest.java:27)
I have switched to the newest JDK 7 and I am having problems with running testng unit test on byte code that is fiddled by emma coverage tool. None of my test cases are run correctly and for most of them I am receiving such errors.
java.lang.ClassFormatError: Illegal local variable table length 10 in method measurement.meter.AbstractSerialPortMeter.<init>(Lmeasurement/meter/SerialPort;)V at measurement.meter.Elc3133aTest.setUp(Elc3133aTest.java:42)
I have found an article here JSR 292 Goodness Fast Code Coverage Tool Less 10k,
which is saying that "JSR 292 introduces a new bytecode instruction invokedynamic but also several new kind of constant pool constants. Which means that most of the tools that parse bytecodes like ASM, BCEL, findbugs or EMMA will need to be updated to be java 7 compatible."
Checked Emma homepage, but it looks like it has not been updated for a long long time.
Has anybody solved a similar problem?
I have also tried with Cobertura. It looks to work a bit better but I am getting a lot of exceptions of type VerifyError
.
java.lang.VerifyError: Expecting a stackmap frame at branch target 85 in method measurement.meter.AbstractSerialPortMeter.close()V at offset 26
at measurement.meter.AbstractSerialPortMeterTest.setUp(AbstractSerialPortMeterTest.java:27)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
我在使用 Maven cobertura 插件时遇到了同样的问题。从 cobertura:report 运行时,所有测试均失败。但是当直接从 Surefire 插件运行时,所有测试都成功了。正如你们中的一些人已经说过的,问题是 coberture 字节码检测与 JDK7 不兼容。
您可以在此处查看 http://vikashazrati.wordpress。 com/2011/10/09/quicktip-verifyerror-with-jdk-7/ 异常与“新类型检查器与StackMapTable 属性”(请参阅:http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html)。
所以我的解决方案是配置surefire-plugin始终使用JVM arg“-XX:-UseSplitVerifier执行测试。无论有没有cobertura检测,它都可以很好地工作。
我在maven中的surefire配置:
I had same problem using maven cobertura plugin. All tests failed when run from cobertura:report. But all tests succeeded when run directly from surefire plugin. As some of you already said the problem is that coberture byte code instrumentation of is not compatible with JDK7.
You can see here http://vikashazrati.wordpress.com/2011/10/09/quicktip-verifyerror-with-jdk-7/ that the exception is related to the "new type checker with StackMapTable attributes" (see: -X:+UseSplitVerifier JVM option in http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html).
So my solution is to configure surefire-plugin to always execute the tests with JVM arg "-XX:-UseSplitVerifier. It works well with and without cobertura instrumentation.
My surefire configuration in maven:
我有同样的问题。
幸运的是 beta 版可以与 JDK 7 配合使用。
更新站点链接:http://download.eclipselab.org/eclemma /beta/2.0.0/update/
这个链接应该在 Eclipse 中使用:
休息应该很容易;)
I had the same issue.
Fortunately beta works with JDK 7.
Update site link: http://download.eclipselab.org/eclemma/beta/2.0.0/update/
This link should be used in Eclipse:
Rest should be easy ;)
我让 Gradle 1.0M9、Java 7 和 EMMA 2.1 使用此处建议的补丁:使用 jvm 参数。
详细信息在这里...
http://marcellodesales.wordpress.com/2012/04/03/running-emma-code-test-coverage-with-java-7-and-gradle-1-0m9/?preview=true& ;preview_id=179&preview_nonce=261e892908
运行“gradle test”给出以下结果:
I got Gradle 1.0M9, Java 7 and EMMA 2.1 working with the patches suggested here: using the jvm argument.
Details here...
http://marcellodesales.wordpress.com/2012/04/03/running-emma-code-test-coverage-with-java-7-and-gradle-1-0m9/?preview=true&preview_id=179&preview_nonce=261e892908
Running "gradle test" gives the following:
如果您不使用新的语言功能(例如 try-with-resources 等),Emma 就可以工作。您可以通过新库(Paths、DirectoryStream 等)来使用 Java 7。
我知道这不能解决您的问题,但如果您只想检查“JDK 7 的执行方式”,它可能会起作用......
Emma works if you do not use new language features (like try-with-resources, etc.). You can use Java 7 using new libraries (Paths, DirectoryStream, etc.).
I know this would be not a solution to your problem, but if you want to only check "how JDK 7 performs" it may work...
我遇到了这个问题。使用 Eclipse 市场升级到 2.0.1.201112281951 对我来说很有效。
I was having this problem. Upgrading to 2.0.1.201112281951 using the Eclipse marketplace worked for me.
IntelliJ IDEA 11 的内部覆盖工具对于我使用 try-with-resources、diamond 运算符的项目运行良好,但我们没有使用 invokedynamic。我认为社区版中不包含覆盖工具,仅包含终极版。
我还没有尝试过 jacoco - 艾玛的大多数前开发人员似乎都已经去了那里。
IntelliJ IDEA 11's internal coverage tool works fine for my project using try-with-resources, diamond operator but we are not using invokedynamic. I think the coverage tool is not included in the community edition, ultimate only.
I have yet to try jacoco - it's where most of emma's former developers seem to have gone.
Java 8+ 相当于 Pedro Ballesteros 的答案是:(
调整版本号以匹配您正在使用的 Surefire 版本。)
The Java 8+ equivalent of the answer by Pedro Ballesteros is:
(Tweak the version number to match the version of Surefire you are using.)