Allowing bytecode-modified classes

[Martin Paljak]

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

[Marc Hoffmann]

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 <martin...@gmail.com> wrote:

Hello,

--
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 visit https://groups.google.com/d/msgid/jacoco/250c8f84-014d-4b51-be8a-8709da2c7715n%40googlegroups.com.

[Martin Paljak]

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!