Error during coverage report generation -[jacoco:report] Execution data for class *** does not match

[JB]

I was getting proper report over last month. And I recently havent made any version updates/changes. 

I see the following error during report generation and it gives only partial coverage. The classes having these errors are skipped from the coverage. 

report-int:
[jacoco:report] Loading execution data file /app/workspace/Functional_Code_Coverage/IRO/merges/jacoco-int-merged.exec
[jacoco:report] Writing bundle 'JaCoCo-INT' with 147 classes
[jacoco:report] Classes in bundle 'JaCoCo-INT' do no match with execution data. For report generation the same class files must be used as at runtime.

[jacoco:report] Execution data for class ******* does not match.
[jacoco:report] Execution data for class ****************** does not match.

Does anyone have this issue earlier?

 jacoco version : acoco-0.7.4.201502262128

 jdk version : 1.8.0_60

[Marc R. Hoffmann]

Hi,

this happens if classes at runtime are different from the class files at report generation time. There is a couple of reasons, why this could happen. Please see our documentation at http://eclemma.org/jacoco/trunk/doc/classids.html

Regards,
-marc

What can cause different class ids?

Class ids are identical for the exact same class file only (byte-by-byte). There is a couple of reasons why you might get different class files. First compiling Java source files will result in different class files if you use a different tool chain:

• Different compiler vendor (e.g. Eclipse vs. Oracle JDK)
• Different compiler versions
• Different compiler settings (e.g. debug vs. non-debug)

Also post-processing class files (obfuscation, AspectJ, etc.) will typically change the class files. JaCoCo will work well if you simply use the same class files for runtime as well as for analysis. So the tool chain to create these class files does not matter.

Even if the class files on the file system are the same there is possible that classes seen by the JaCoCo runtime agent are different anyways. This typically happens when another Java agent is configured before the JaCoCo agent or special class loaders pre-process the class files. Typical candidates are:

• Mocking frameworks
• Application servers
• Persistence frameworks