Hi @Godin I wonder whether this change has side effects: So far we did not process synthetic classes at all and did not report them. Now we process them and report them to ICoverageVisitor.visitCoverage(). I wonder whether synthetic classes will now show up as empty classes in our reports?

@marchof see #817 - since quite some time "empty" classes do not increase counters and we deliberately preserve them in our XML reports, while do not show in HTML and CSV reports.

So new behavior in respect to synthetic classes is IMO not quite new in respect to empty classes. And more consistent - for example for the following Example.java as well as for other cases of synthetic and empty classes

enum Example {
  E;
  static void example(Example e) {
    switch (e) {
    }
  }
  public static void main(String[] args) {
    example(E);
  }
}
interface I {
}

execution of

javac Example.java -d classes && ls -1 classes

shows 3 produced class files

I.class
Example$1.class
Example.class

and execution of

java -javaagent:jacoco-0.8.14/lib/jacocoagent.jar -cp classes Example
java -jar jacoco-0.8.14/lib/jacococli.jar execinfo jacoco.exec

clearly shows

[INFO] Loading exec file jacoco.exec.
CLASS ID         HITS/PROBES   CLASS NAME
Session "MAC9003-da920919": Wed Jan 28 15:49:06 CET 2026 - Wed Jan 28 15:49:06 CET 2026
c966c402206c6798    1 of   1   Example$1
c3e55ed53a7558c1    7 of   8   Example

that execution data contains Example$1 even without this change, however execution of

java -jar jacoco-0.8.14/lib/jacococli.jar classinfo classes

without this change does not show this class while shows empty class of interface

  INST   BRAN   LINE   METH   CXTY   ELEMENT
     0      0      0      0      0   class 0x7b2d6d0c22f5309f I
    18      0      6      3      3   class 0xe6c876fba2f4b842 Example

and after this change will show

  INST   BRAN   LINE   METH   CXTY   ELEMENT
     0      0      0      0      0   class 0x7b2d6d0c22f5309f I
    18      0      6      3      3   class 0xe6c876fba2f4b842 Example
     0      0      0      0      0   class 0xc966c402206c6798 Example$1

Note that as far as I know Java compiler generates synthetic classes only in two cases:

• for switch by enum
• and for private constructor of nested class prior to https://openjdk.org/jeps/181 in Java 11

Also after this change will be unambiguously clear that classes not presented in XML report are the ones that user explicitly excluded or not included from/into analysis.

Of course this PR can be changed to read SMAPs from synthetic classes while not passing them to ICoverageVisitor.visitCoverage, however then for

• Do not filter-out @JvmSynthetic classes in Kotlin #1846
• Do not filter-out @JvmMultifileClass in Kotlin #1843

(in both Kotlin compiler generates synthetic classes whose content should appear in coverage reports)

one will need new internal filtering API to be able to exclude class from visitCoverage rather than simply (re)using existing code and of this PR, which given all the above IMO unnecessary increase of complexity.

We also briefly discussed such change some time ago, but at that time it was postponed - see #668 (comment) Seems that time to reconsider has come 😉

Many thanks for the detailed explanation!

@marchof actually I forgot one more case of synthetic class in Java - package-info 😞

if users in case of split packages perform analysis without proper split on bundles and for the same package there are two package-info.class with different classId, ie in case of

src1/org/example/A.java

class A {
}

src1/org/example/package-info.java

package org.example;

src2/org/example/B.java

package org.example;
class B {
}

src2/org/example/package-info.java

@Deprecated
package org.example;

execution of

javac \
  src1/org/example/package-info.java \
  src1/org/example/A.java \
  -d classes1

javac \
  src2/org/example/package-info.java \
  src2/org/example/B.java \
  -d classes1

java -jar jacococli.jar \
  report \
  --classfiles classes1 \
  --classfiles classes2 \
  --html report

after this change will lead to

java.lang.IllegalStateException: Can't add different class with same name: org/example/package-info

Unfortunately to get aggregated reports users have (or at least had in past) tendency to mix multiple modules without proper split on bundles - see #858 which was about module-info.class, and while probability to get such exception in case of package-info.class might be lower, it is not zero unfortunately.

As is one will need to explicitly exclude **/package-info.class from analysis, which might be not a big deal for the ones who have exclusions for split packages with already conflicting other classes.

Or we can restore exclusion of synthetic classes in Analyzer, but only for package-info, or exclude it prior to duplicate check in CoverageBuilder, or some other option.

WDYT?

@Godin I don't see a use case of package-info.class files in our reports, especially as they never contain code. I would therefore hard-code the filtering of module-info and package-info in the analyzer.