Can't recognize classes that have been pack200'd

[mickaelistria]

When using classes coming from jars that have been pack200'd, later reports (may them be provided by Ant or EclEmma) don't succeed to map the class found in jacoco.exec with classes part of the pack200'ed jars; and then report 0% coverage on those classes.

How to reproduce:

1. Clone the following repo https://github.com/mickaelistria/bug-jacoco-pack200
2. cd api; mvn verify will build a p2 update-site
3. cd client; mvn verify will consume a dependency from this p2 site and will run a test
4. Import api/org.jboss.tools.example.api into Eclipse (as a Maven project), import coverage session from client/target/jacoco.exec with EcliEmma
5. Note coverage is good (~57%); then
6. cd api; mvn clean verify -Ppack200 will generate a p2 repo including pack200'ed jar
7. cd client; mvn verify; will re-run test, but will resolve to the packed bundle instead of plain jar
8. Go back to the coverage view in Eclipse, reload it: Coverage is now 0%

You can make the same experiment with Ant, or Jenkins Jacoco plugin instead of EclEmma.

The content of the jacoco.exec file looks good, but something (class id?) is changed and prevent reports for matching source/class files with what's found in the jacoco.exec.

[marchof]

Indeed it is a known issue that Pack200 modifies class files, which is an issue for example for JAR signing:

http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/pack200.html

The only solution I can think about is to add direct support for Pack200 to the JaCoCo analyzer. If both your program under test and the JaCoCo analyzer will read the Pack200 JAR they should see the same class files. This would require to run the analysis on the Pack200 JAR, not on the class files.

If this is a solution for you, please open an issue for the JaCoCo project to support Pack200 format for analysis.

[mickaelistria]

On 03/19/2013 10:19 PM, Marc R. Hoffmann wrote:

Indeed it is a known issue that Pack200 modifies class files, which is
an issue for example for JAR signing:

http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/pack200.html

Ok, thanks,

The only solution I can think about is to add direct support for
Pack200 to the JaCoCo analyzer. If both your program under test and
the JaCoCo analyzer will read the Pack200 JAR they should see the same
class files. This would require to run the analysis on the Pack200
JAR, not on the class files.

If this is a solution for you, please open an issue for the JaCoCo
project to support Pack200 format for analysis.

That would be a solution for standalone reports, so I opened this issue
for jacoco: jacoco/jacoco#91
However I don't think that would help for EclEmma, whould it? Isn't the
fully qualified name of the class enough to map coverage reports with

ICompilationUnit files in Eclipse?

Mickael Istria
Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools
My blog http://mickaelistria.wordpress.com - My Tweets
http://twitter.com/mickaelistria

[marchof]

Isn't the fully qualified name of the class enough to map coverage reports with ICompilationUnit files in Eclipse?

Unfortunetelly it is not: If the class gets modified for any reason (Pack200, AspectJ, Mocking Frameworks, ...) JaCoCo will miserable fail or produce random results.

[marchof]

This issue has been transferred to jacoco/jacoco#91

[mickaelistria]

I got another occurrence of this issue and it leads me to further questions:
Does EclEmma use classes generated by JDT to show reports? If yes, then do you think it would be possible to configure an additional builder that pack200 the class files in Eclipse? If so would EclEmma see class files that match the one it got on runtime and be able to report good coverage?

[marchof]

When you import a exec file into Eclipse the classes at runtime have to be the same class files then the ones compiled by Eclipse. Unfortunately there can be a couple of reasons why the class files might differ:

1. Different compiler (ECJ vs. JDK)
2. Different compiler settings (e.g. debug symbols)
3. Post-processing (e.g. with Pack200)

[mickaelistria]

On 01/08/2014 01:05 AM, Marc R. Hoffmann wrote:

When you import a exec file into Eclipse the classes at runtime have
to be the same class files then the ones compiled by Eclipse.
Unfortunately there can be a couple of reasons why the class files
might differ:

1. Different compiler (ECJ vs. JDK)
2. Different compiler settings (e.g. debug symbols)
3. Post-processing (e.g. with Pack200)

Thanks, I understand it better and better.
Is it possible to EclEmma to detect that classes don't match (for any of
these reasons) and warn explaining the error, and even better, proposing

to UI to choose some alternatives classes/jars to process report?

Mickael Istria
Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools
My blog http://mickaelistria.wordpress.com - My Tweets
http://twitter.com/mickaelistria

[marchof]

@mickaelistria Nice idea, can you please open a feature request for this?

[mickaelistria]

Here is the feature request: #74