Zero code coverage on classes that were previously instrumented by PowerMock

[Shaykin Anton]

This is a well-known issue, which makes it impossible to use such a great tool in our project.

I know this has been previously discussed here and here and in many other places. Just as a reminder, "JaCoCo uses a hashcode of the class definition for class identity" that's why it can't determine coverage on classes which were instrumented by PowerMock.

I also know, that the official answer is "This is a known limitation we can't currently do anything about". Pardon for being persistent, but maybe I can give you a hand in fixing this problem?

[Marc R. Hoffmann]

> Pardon for being persistent, but
> maybe I can give you a hand in fixing this problem?

Absolutely! A great starting point would be to have somebody in the loop
who really understands both, JaCoCo and PowerMock/JMockit etc. worlds.
I'm happy with providing any information about JaCoCo, but we don't have
resources to analyze the implementation of different mocking tools.

If the mocking tools could be configured to play better with other
agents (i.e. transform the classes already by JaCoCo, not the original
ones) it is probably easily possible to combine both tools.

Cheers,
-marc

On 16.06.13 21:08, Shaykin Anton wrote:
> This is a well-known issue, which makes it impossible to use such a
> great tool in our project.
>
> I know this has been previously discussed here

> <https://code.google.com/p/powermock/issues/detail?id=402> and here
> <https://github.com/jacoco/eclemma/issues/15> and in many other places.

> Just as a reminder, "JaCoCo uses a hashcode of the class definition for
> class identity" that's why it can't determine coverage on classes which
> were instrumented by PowerMock.
>
> I also know, that the official answer is "This is a known limitation we
> can't currently do anything about". Pardon for being persistent, but
> maybe I can give you a hand in fixing this problem?
>

> --
> You received this message because you are subscribed to the Google
> Groups "JaCoCo and EclEmma Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jacoco+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Shaykin Anton]

Sorry, don't have much time for this, but still interested in solving this problem. Could you please, elaborate on why the decision was made to use a hashcode for class identity? Is it possible to change this decision?

Regards,

Anton.

[Marc Hoffmann]

Hi Anton,

there are two reasons for this design:

JaCoCo should support multiple versions of classes in the same VM. This
is a typical scenario in application servers or OSGi container. I
understand that in some situations (like unit testing with mocking
framework) this feature is questionable.

The other reason is a limitation of the way hot JaCoCo implements code
coverage analysis: At runtime (instrumentation) as well as during
analysis every class file is analyzed for its internal control
structures. For the specific control structure a list of positions for
probes if calculated, every probe gets an index 0...n. For
instrumentation extra byte code is inserted at these positions which
toggles a flag with the respective index. The JaCoCo runtime collects
the flags for every class (represented as an boolean array) and e.g.
writes it to the exec file.

During analysis the same class is analyzed again for its internal
control structure to calculate probe positions. From these positions and
the information which probes has been executed (e.g. read from exec
files) all metrics are interfered: Instructions, branches, probes, lines
etc. But this works only for the exact same class file. If you do
analysis on a different class file (different ordering of methods,
additional/loss methods, extra/less code in methods) you will end-up
with different probes. Thereefore JaCoCo requires the exact same class
file at analysis as at runtime. This is guaranteed by the hash.

Cheers,
-marc

>>> <https://code.google.com/p/powermock/issues/detail?id=402 [1]> and
>> here
>>> <https://github.com/jacoco/eclemma/issues/15 [2]> and in many

>> other places.
>>> Just as a reminder, "JaCoCo uses a hashcode of the class
>> definition for
>>> class identity" that's why it can't determine coverage on classes
>> which
>>> were instrumented by PowerMock.
>>>
>>> I also know, that the official answer is "This is a known
>> limitation we
>>> can't currently do anything about". Pardon for being persistent,
>> but
>>> maybe I can give you a hand in fixing this problem?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>
>>> Groups "JaCoCo and EclEmma Users" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>> send
>>> an email to jacoco+un...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out

>> [3].

>>>
>>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "JaCoCo and EclEmma Users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to jacoco+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out

> [4].
>
>
>
> Links:
> ------
> [1] https://code.google.com/p/powermock/issues/detail?id=402
> [2] https://github.com/jacoco/eclemma/issues/15
> [3] https://groups.google.com/groups/opt_out
> [4] https://groups.google.com/groups/opt_out

[javasa...@gmail.com]

I am also facing this issue(Jacoco and Powermock). Please let me know if somebody had solution.

[Marc R. Hoffmann]

Hi,

a possible workaround is to pre-instrument your class files on disk
(offline instrumentation). Evgeny prepared an example for JMockit, it
should also work for Powermock:

https://github.com/Godin/jacoco-experiments/tree/master/jacoco-jmockit-example

Cheers,
-marc

[Santhi Java]

Thanks Marc,

I tried this solution,  but now i could see the coverage only for the classes which is using powemock. It is not covering for the normal Junit and DBunit classes.

is this issue is going to fix in next releases.

Thanks again,

Santhi

--
You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jan Pešta]

Hi,

I know this is quite old question.

Is there some solution which is usable?

If not, is there a way how to pass bytecode to jacoco just before manipulation of Mockers/or other tools ?

I am playing with eclemma and I am unable to get registered class transformer from jacoco.

Thanks,
Jan

Dne úterý 27. srpna 2013 20:55:49 UTC+2 Santhi Java napsal(a):

To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+un...@googlegroups.com.

[Marc Hoffmann]

Hi,

there are two possible workarounds that might wirk in certain
situations:

1) Make sure the JaCoCo agent is specified as the very first agent
(before the mocking agents), if the mocking frameworks do work with
agents.

2) Use JaCoCo with its offline instrumentation feature (not available in
EclEmma thogh).

Regards,
-marc

>> [1]

>>
>> Cheers,
>> -marc
>>
>> On 22.08.13 23:49, javasa...@gmail.com wrote:
>> On Sunday, June 16, 2013 12:08:20 PM UTC-7, Shaykin Anton wrote:
>> This is a well-known issue, which makes it impossible to use such a
>> great tool in our project.
>>
>> I know this has been previously discussed here and here and in many
>> other places. Just as a reminder, "JaCoCo uses a hashcode of the
>> class definition for class identity" that's why it can't determine
>> coverage on classes which were instrumented by PowerMock.
>>
>> I also know, that the official answer is "This is a known limitation
>> we can't currently do anything about". Pardon for being persistent,
>> but maybe I can give you a hand in fixing this problem?
>>
>> I am also facing this issue(Jacoco and Powermock). Please let me
>> know if somebody had solution.
>
> --
> You received this message because you are subscribed to the Google
> Groups "JaCoCo and EclEmma Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jacoco+un...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out [2].

>
> --
> You received this message because you are subscribed to the Google
> Groups "JaCoCo and EclEmma Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jacoco+un...@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jacoco/798ba88a-2c53-423e-b2d8-d4b7187d0212%40googlegroups.com
> [3].
> For more options, visit https://groups.google.com/d/optout [4].
>
>
> Links:
> ------
> [1]
> https://github.com/Godin/jacoco-experiments/tree/master/jacoco-jmockit-example
> [2] https://groups.google.com/groups/opt_out
> [3]
> https://groups.google.com/d/msgid/jacoco/798ba88a-2c53-423e-b2d8-d4b7187d0212%40googlegroups.com?utm_medium=email&utm_source=footer
> [4] https://groups.google.com/d/optout

[Jan Pešta]

Hi,

Thanks for the answer, but it doesn't help.

Think is that I am manipulating byte code in Junits by my self, and I would like to call jacoco, before my, because when I pass bytecode to define method (which ends in jacoco) it must be manipulated already.

I was thinking if there is some non native implementation, which is able to provide registered ClassFileTransformer and I can pass byte code to them before my manipulation.

Thanks,
Jan


Dne čtvrtek 30. července 2015 16:25:14 UTC+2 Marc R. Hoffmann napsal(a):

[Marc Hoffmann]

Hi Jan,

correct, bytecode is processed by Java agents when define class is
called -- so probably after you do the manipulation. So the only option
left is to use offline instrumentation, i.e. instrument the classes on
disk before you execute your tests.

Regards,
-marc

>> [2] [2].

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>
>>> Groups "JaCoCo and EclEmma Users" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>> send
>>> an email to jacoco+un...@googlegroups.com.
>>> To view this discussion on the web visit
>>>
>>
> https://groups.google.com/d/msgid/jacoco/798ba88a-2c53-423e-b2d8-d4b7187d0212%40googlegroups.com
>> [3]
>>> [3].
>>> For more options, visit https://groups.google.com/d/optout [4]
>> [4].
>>>
>>>
>>> Links:
>>> ------
>>> [1]
>>>
>>
> https://github.com/Godin/jacoco-experiments/tree/master/jacoco-jmockit-example

>> [1]
>>> [2] https://groups.google.com/groups/opt_out [2]
>>> [3]
>>>
>>
> https://groups.google.com/d/msgid/jacoco/798ba88a-2c53-423e-b2d8-d4b7187d0212%40googlegroups.com?utm_medium=email&utm_source=footer
>> [5]
>>> [4] https://groups.google.com/d/optout [4]

>
> --
> You received this message because you are subscribed to the Google
> Groups "JaCoCo and EclEmma Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jacoco+un...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jacoco/1ae73837-9cff-4ae1-8117-c3c68b8d0a9c%40googlegroups.com
> [6].

> For more options, visit https://groups.google.com/d/optout [4].
>
>
> Links:
> ------
> [1]
> https://github.com/Godin/jacoco-experiments/tree/master/jacoco-jmockit-example
> [2] https://groups.google.com/groups/opt_out
> [3]
> https://groups.google.com/d/msgid/jacoco/798ba88a-2c53-423e-b2d8-d4b7187d0212%40googlegroups.com

> [4] https://groups.google.com/d/optout
> [5]
> https://groups.google.com/d/msgid/jacoco/798ba88a-2c53-423e-b2d8-d4b7187d0212%40googlegroups.com?utm_medium=email&amp;utm_source=footer
> [6]
> https://groups.google.com/d/msgid/jacoco/1ae73837-9cff-4ae1-8117-c3c68b8d0a9c%40googlegroups.com?utm_medium=email&utm_source=footer