Sonar (jacoco) + jmockit spamming with exceptions

Question

I ran into a bug that is starting to really annoy.
Here is what I have: 1) Sonar 3.5, which uses JaCoCo as a coverage tool. 2) Jmockit lib for testing using mocks. 3) The build process automated with maven.

So, when I run mvn clean install , which is fine, and then I run mvn sonar:sonar and what happens here:

• Jmockit seems to be the instrumental classes that it needs.
• JaCoCo cannot host tool classes that are already instrumented by Jmockit and spits out a HUGE amount of exceptions, saying that this is not possible for a tool class that has already been instrumented. However, it seems that Sonar has a valid result for such a scenario.
  So the first question is: can I somehow suppress such exceptions? This is really important because the size of the log file in our CI system reaches 50Mb (!), Which is unacceptable. A lot of free space is simply eaten up by such magazines on our CI machine.

Here are the exceptions I have:

 java.lang.instrument.IllegalClassFormatException: Error while instrumenting class app/MyClass. Caused by: java.lang.IllegalStateException: Class app/MyClass is already instrumented. 

Assuming that it is impossible to exclude such exceptions, I studied it a bit and found out that JaCoCo (a tool that uses Sonar and a tool that cannot have tools with tool classes) has a mode such as offline instrumentation (AFAIK Sonar does not support this offline instrumentation or may suppress such warnings). This item is intended to be used specifically for such cases. So I tried to configure JaCoCo as a plugin in maven, but I was not able to do this. JaCoCo cannot find the execution file. When I run mvn clean install , the following message appears:

[INFO] --- jacoco-maven-plugin: 0.6.2.201302030002: report (report) @ webservice-mws --- [INFO] JaCoCo execution skip due to missing execution data file

If I am not mistaken, this executable is the RESULT of the JaCoCo plugin. I am completely upset and do not know what to do with it.

If someone can help me, it will be very appreciated! Thanks in advance!

my pom.xml settings for the JaCoCo plugin:

  <plugin> <groupId>org.jacoco</groupId> <artifactId>jacoco-maven-plugin</artifactId> <version>0.6.2.201302030002</version> <executions> <execution> <phase>process-test-resources</phase> <goals> <goal>prepare-agent</goal> </goals> </execution> <execution> <id>report</id> <phase>verify</phase> <goals> <goal>report</goal> </goals> </execution> </executions> </plugin> 

Answer 1

You can use Cobertura as a code cover for Sonar 3.5.1.

To change it:

• Login as admin
• Go to Settings> Configuration
• Under General Settings> Java
• Install code coverage plugin = cobertura

Worked like the charm of my project ^ _-

Answer 2

As far as I know, the message "Class / MyClass application is already installed." means that this class has already been developed by JaCoCo. Here are some of the possible reasons why this could happen:

• online equipment mixed with online ones should be used exclusively
• two JaCoCo agents attached to the JVM during tests - this can happen because Sonar tries to automatically attach the JaCoCo agent and run the tests, and the jacoco-maven-plugin also attaches the agent, so take a look at the "sonar" property to avoid this. dynamicAnalysis = reuseReports "or not use jacoco-maven-plugin, and Sonar will do its job on its own

For me, your message looks a little complicated to understand the configuration, so I can’t say exactly which of the cases you encountered above, but my bet is on the second.

Hope this information is helpful to you. Feel free to return to the Sonar user mailing list if this does not help you solve the problem.

Answer 3

According to my understanding of this study: you can also use classes with stand-alone hardware with the JaCoCo Java agent. In this case, the configuration is taken from the agent options. The agent must be configured so that excluded classes are excluded, for example. with "exclude = *". Otherwise, this will lead to error messages on the console if the agent also runs similar classes again and again in your case. Record plugin Jacoco: -

 <configuration> <excludes> <exclude>*</exclude> </excludes> </configuration> 

The jacocoagent.jar agent is part of the JaCoCo distribution and includes all the necessary dependencies. The Java agent can be activated using the following JVM option (on the command line):

 -javaagent:[yourpath/]jacocoagent.jar=[option1]=[value1],[option2]=[value2] 

For JaCoCo agent settings, consider the following link: http://www.jacoco.org/jacoco/trunk/doc/agent.html

Since the jacocoagent.jar agent is part of the JaCoCo distribution, it is automatically included in the argLine parameter and does not need to be explicitly specified, but we need to check if jacocoagent.jar is displayed as set in argLine when the mvn clean install command is run

Answer 4

I had the same problem. It seems to be fixed in jacoco plugin 0.7.1+. I am using 0.7.3.201502191951 and the problem is gone for me.

Essentially, the jMockit agent downloads the classes and relays them before the JaCoCo agent sees them. Subsequently, JaCoCo will no longer be able to carry out the required devices. see link

https://github.com/jacoco/jacoco/issues/208

Answer 5

The problem is that JMockit "reloads" the class to mimic them. Then JaCoCo will try to pin them again. At this point an error occurs.

Note. This does not happen for mocking interfaces.

When starting EclEmma + JaCoCo

see the following stack:

 java.lang.instrument.IllegalClassFormatException: Error while instrumenting class com/company/AbstractClass. at org.jacoco.agent.rt.internal_9dd1198.CoverageTransformer.transform(CoverageTransformer.java:89) at sun.instrument.TransformerManager.transform(TransformerManager.java:188) at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:424) at sun.instrument.InstrumentationImpl.redefineClasses0(Native Method) at sun.instrument.InstrumentationImpl.redefineClasses(InstrumentationImpl.java:170) at mockit.internal.startup.Startup.redefineMethods(Startup.java:260) at mockit.internal.RedefinitionEngine.redefineClasses(RedefinitionEngine.java:26) at mockit.internal.expectations.mocking.BaseTypeRedefinition.redefineClass(BaseTypeRedefinition.java:172) at mockit.internal.expectations.mocking.BaseTypeRedefinition.redefineClassAndItsSuperClasses(BaseTypeRedefinition.java:147) at mockit.internal.expectations.mocking.BaseTypeRedefinition.redefineMethodsAndConstructorsInTargetType(BaseTypeRedefinition.java:134) at mockit.internal.expectations.mocking.BaseTypeRedefinition.redefineTargetClassAndCreateInstanceFactory(BaseTypeRedefinition.java:197) at mockit.internal.expectations.mocking.BaseTypeRedefinition.redefineType(BaseTypeRedefinition.java:57) at mockit.internal.expectations.mocking.TypeRedefinition.redefineType(TypeRedefinition.java:47) at mockit.internal.expectations.mocking.SharedFieldTypeRedefinitions.redefineTypeForMockField(SharedFieldTypeRedefinitions.java:60) at mockit.internal.expectations.mocking.FieldTypeRedefinitions.redefineFieldType(FieldTypeRedefinitions.java:48) at mockit.internal.expectations.mocking.FieldTypeRedefinitions.redefineFieldTypes(FieldTypeRedefinitions.java:38) at mockit.internal.expectations.mocking.SharedFieldTypeRedefinitions.redefineTypesForTestClass(SharedFieldTypeRedefinitions.java:43) at mockit.integration.internal.TestRunnerDecorator.handleMockFieldsForWholeTestClass(TestRunnerDecorator.java:135) at mockit.integration.internal.TestRunnerDecorator.updateTestClassState(TestRunnerDecorator.java:34) at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.handleMockingOutsideTestMethods(JUnit4TestRunnerDecorator.java:107) at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:37) at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:32) at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at mockit.internal.util.MethodReflection.invokeWithCheckedThrows(MethodReflection.java:106) at mockit.internal.mockups.MockMethodBridge.callMock(MockMethodBridge.java:85) at mockit.internal.mockups.MockMethodBridge.invoke(MockMethodBridge.java:44) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: java.io.IOException: Error while instrumenting class com/afklm/cco/slt/integrator/batch/AbstractData. at org.jacoco.agent.rt.internal_9dd1198.core.instr.Instrumenter.instrumentError(Instrumenter.java:147) at org.jacoco.agent.rt.internal_9dd1198.core.instr.Instrumenter.instrument(Instrumenter.java:98) at org.jacoco.agent.rt.internal_9dd1198.CoverageTransformer.transform(CoverageTransformer.java:87) ... 44 more Caused by: java.lang.IllegalStateException: Class com/company/AbstractClass is already instrumented. at org.jacoco.agent.rt.internal_9dd1198.core.internal.instr.InstrSupport.assertNotInstrumented(InstrSupport.java:81) at org.jacoco.agent.rt.internal_9dd1198.core.internal.instr.ClassInstrumenter.visitField(ClassInstrumenter.java:79) at org.jacoco.agent.rt.internal_9dd1198.asm.ClassVisitor.visitField(Unknown Source) at org.jacoco.agent.rt.internal_9dd1198.asm.ClassReader.a(Unknown Source) at org.jacoco.agent.rt.internal_9dd1198.asm.ClassReader.accept(Unknown Source) at org.jacoco.agent.rt.internal_9dd1198.asm.ClassReader.accept(Unknown Source) at org.jacoco.agent.rt.internal_9dd1198.core.instr.Instrumenter.instrument(Instrumenter.java:78) at org.jacoco.agent.rt.internal_9dd1198.core.instr.Instrumenter.instrument(Instrumenter.java:96) ... 45 more