Jacoco doesn't cover a class that is an injection by constructor

[mpumd]

Describe the bug

Hi guys

Today we have a coverage problem with jacoco. An ApplicationScope bean that use an injection by constructor isn't cover by jacoco.

Expected behavior

Jacoco should cover all classes, whatever the way of dependency injection.

Actual behavior

No response

How to Reproduce?

You have an example project by file zip file just at the end of this message.

Output of uname -a or ver

MSYS_NT-10.0-19045 3.3.6-bec3d608-341.x86_64 2023-02-22 08:29 UTC x86_64 Msys

Output of java -version

Java version: 17.0.6, vendor: BellSoft, runtime: scoop\apps\liberica17-full-jdk\current

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.16.5.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)

Additional information

jacoco.zip

Thanks !

[quarkus-bot]

/cc @Ladicek (arc), @manovotn (arc), @mkouba (arc)

[vsevel]

when we use the injection by constructor, we see:

[INFO] --- jacoco-maven-plugin:0.8.8:report (report) @ getting-started ---
[INFO] Loading execution data file E:\tmp\getting-started-jacoco\target\jacoco.exec
[INFO] Analyzed bundle 'getting-started' with 3 classes
[WARNING] Classes in bundle 'getting-started' do not match with execution data. For report generation the same class files must be used as at runtime.
[WARNING] Execution data for class org/acme/MyBean does not match.

and /target/site/jacoco/org.acme/MyBean.java.html#L11 has 0 coverage.

instead of:

[INFO] --- jacoco-maven-plugin:0.8.8:report (report) @ getting-started ---
[INFO] Loading execution data file E:\tmp\getting-started-jacoco\target\jacoco.exec
[INFO] Analyzed bundle 'getting-started' with 3 classes

[mkouba]

I'm not a jacoco expert but if you use constructor injection for an @ApplicationScoped bean that does not declare a no-args constructor then the class is transformed and a no-args constructor is added - that might be the reason why you get the warning.

Speaking of coverage - does jacoco hanlde CDI at all. I mean the bean is not instantiated directly in the code, so it would need to analyze the injection points (e.g. GreetingResource#myBean) and deduce that the injected bean is used...

[vsevel]

you are right @mkouba: a default constructor with package or public visibility makes jacoco happy (does not work with private).

[manovotn]

you are right @mkouba: a default constructor with package or public visibility makes jacoco happy (does not work with private).

Martin is right, the CDI specification requires that every bean with normal scope (which is, among others, @ApplicationScoped) has a non-private no-args constructor. This is for purposes of client proxy creation. Quarkus can bypass this rule by letting you not declare it and then generating it later during build automagically. Hence the jacoco complaint.

In fact, there is more bytecode tempering Quarkus can do (and not just in CDI), so technically you should feed jacoco the sources after Quarkus finishes build, but I am not sure that's possible 🤔

[vsevel]

In fact, there is more bytecode tempering Quarkus can do (and not just in CDI), so technically you should feed jacoco the sources after Quarkus finishes build, but I am not sure that's possible

hmm. that would be nice. especially because jacoco fails on the class silently (just a warn in the build logs).
the only reason we spotted it was because we failed the coverage quality gate on sonar.

[manovotn]

In fact, there is more bytecode tempering Quarkus can do (and not just in CDI), so technically you should feed jacoco the sources after Quarkus finishes build, but I am not sure that's possible

hmm. that would be nice. especially because jacoco fails on the class silently (just a warn in the build logs). the only reason we spotted it was because we failed the coverage quality gate on sonar.

Hm, you can dump the generated classes, so that might be a start if you want to play with it, see https://quarkus.io/guides/writing-extensions#dump-the-generated-classes-to-the-file-system
(the link is about writing extensions but it nicely describes the options)

[Ladicek]

I'd like to point out that there is no source code that could be matched with transformed bytecode. If the coverage tool tries to match source code with bytecode, that will inevitably fail in presence of bytecode transformations and there's nothing we can do about that.

[geoand]

IIRC, Jacoco skips over code if it has the synthetic modifier, but I was also under the impression that Arc does add that modifier when it adds a no-args constructor

[geoand]

This seems to indicate that we do add the proper modifier.

[geoand]

Maybe the fact that it's public is causing the problem? Can the constructor be made package private @mkouba @manovotn ?

[geoand]

In any case, I opened: #32267. Would anyone be able to try it on their application?

[manovotn]

IIRC, Jacoco skips over code if it has the synthetic modifier, but I was also under the impression that Arc does add that modifier when it adds a no-args constructor

Interesting, didn't know that.

Maybe the fact that it's public is causing the problem? Can the constructor be made package private @mkouba @manovotn ?

Yes, that should work. CDI needs any non-private.

[vsevel]

does not seem to happen when using the quarkus jacoco extension

[geoand]

Thanks for the update @vsevel