Hello,
I managed to get things working and also automated, with my currently Maven
based setup, initially with the help of the ticket instructing to invoke
Ant for report generation rather than depend on the straightforward
assumptions of Maven plugin.
The setup of this specific project does not use agents, rather a customized
classloader that introduces branch flips and other shenanigans to the
bytecode on the go. This meant that there were always at least two class
instances, one in the main app classloader telling the specialized
classloader "please take this class and modify it", and the other in the
modifying classloader.
In fact, I re-modelled the bytecode instrumentation a bit according to what
JaCoCo does, to make the transformation deterministic, and only have a
single additional class definition (before there were hundreds of different
variations of the class during one run, all with different branch flips)
It would help to change the documentation to say that "exclude classloader
names" are _class names_ of classloaders (*AppClassLoader), not the newer
java classloader name ("app"). Maven docs did not have the default value
hint that the plain agent instructions have.
Once I got it to ignore all other classloaders except the one I was
interested in, and made the class modifications deterministic on bytecode
and thus class identity level, things went smoother. I shall write at some
point an explanation what it does, how it does, and how it interacts with
JaCoCo (classdump, classloader exclusion etc)
Next thing to tackle is how exceptions are handled, but that will be a
separate post.
Many thanks for working on a great toolkit!
On Sunday, 16 November 2025 at 12:42:54 UTC+2 Marc R. Hoffmann wrote:
> Hi Martin,
>
> in such situations our recommendation is to do your transformation after
> JaCoCo‘s transformation. Typically this is a matter of the sequence how
> Java agents are provided on the command line.
>
> Cheers,
> -marc
>
> On 16. Nov 2025, at 09:54, Martin Paljak <[email protected]> wrote:
>
> Hello,
>
>
> I'm doing some on-the-fly bytecode modification, not changing the line
> information (basically flipping a few conditional jumps or switches) and
> would like to still get the code coverage somehow from JaCoCo.
>
> Is there any designed pathway for this? I've read the design doc about Java
> Class Identity.
>
> And with no surprises, I get the expected warning and 0% coverage in the
> resulting report (with Maven):
>
> [*WARNING*] Classes in bundle 'jcardengine' do not match with execution
> data. For report generation the same class files must be used as at runtime.
>
> [*WARNING*] Execution data for class
> pro/javacard/engine/testapplets/FaultApplet does not match.
>
> Before I dig into JaCoCo source to look for hacky workarounds, is there
> some recommended course of action to take?
>
> Best,
> Martin
>
> --
> 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 [email protected].
> To view this discussion visit
> https://groups.google.com/d/msgid/jacoco/250c8f84-014d-4b51-be8a-8709da2c7715n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jacoco/250c8f84-014d-4b51-be8a-8709da2c7715n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/jacoco/b46dcacb-4c3b-4112-8fba-551e21c206b4n%40googlegroups.com.
