JaCoCo version 0.8.15 can already be used with JDK 28 EA to measure coverage of code compiled for Java 27 and earlier. And we wanna believe that for such use-case no additional changes will be required.
However newer JaCoCo version is required to measure coverage of code compiled for Java 28 - #2162
We wanna believe that only above change will be enough to measure coverage for code that does not use preview features.
However for code that uses certain preview features, such as value classes, even more changes will most likely be required.
Coverage of code compiled for Java 27 and earlier when executed on JDK 28 EA
As proof JaCoCo 0.8.15 itself builds successfully with JDK 28 EA even without #2162:
git checkout v0.8.15
./mvnw clean package -Dbytecode.version=27 -projects '!org.jacoco.benchmarks'
...
Java version: 28-ea, vendor: Oracle Corporation, runtime: /Users/evgeny.mandrikov/.java-select/versions/openjdk-28-ea+1_macos-aarch64_bin
...
[INFO] BUILD SUCCESS
Use of Java 28 classes from platform class loader
With JaCoCo 0.8.15 use of Java 28 classes from platform class loader leads to exceptions such as
Caused by: java.io.IOException: Error while instrumenting java/sql/Timestamp with JaCoCo 0.8.15.202606040825/6c5260a.
at org.jacoco.agent.rt.internal_bac9136.core.instr.Instrumenter.instrumentError(Instrumenter.java:161)
at org.jacoco.agent.rt.internal_bac9136.core.instr.Instrumenter.instrument(Instrumenter.java:111)
at org.jacoco.agent.rt.internal_bac9136.CoverageTransformer.transform(CoverageTransformer.java:92)
... 15 more
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 72
at org.jacoco.agent.rt.internal_bac9136.asm.ClassReader.<init>(ClassReader.java:200)
at org.jacoco.agent.rt.internal_bac9136.asm.ClassReader.<init>(ClassReader.java:180)
at org.jacoco.agent.rt.internal_bac9136.asm.ClassReader.<init>(ClassReader.java:166)
at org.jacoco.agent.rt.internal_bac9136.core.internal.instr.InstrSupport.classReaderFor(InstrSupport.java:280)
at org.jacoco.agent.rt.internal_bac9136.core.instr.Instrumenter.instrument(Instrumenter.java:77)
at org.jacoco.agent.rt.internal_bac9136.core.instr.Instrumenter.instrument(Instrumenter.java:109)
... 16 more
that indicate inability to measure coverage of only mentioned class without any impacts on coverage measurement for other classes.
To get rid of such exceptions agent option exclclassloader can be used
'exclclassloader=jdk.internal.loader.ClassLoaders$PlatformClassLoader'
Such classes will be excluded by default in JaCoCo 0.8.16-SNAPSHOT - see #2152
Generation of coverage report for Java 28 class files
With JaCoCo 0.8.15 attempt to generate coverage report for Java 28 class files leads to
Exception in thread "main" java.io.IOException: Error while analyzing Example.class with JaCoCo 0.8.15.202606040825/6c5260a.
at org.jacoco.cli.internal.core.analysis.Analyzer.analyzerError(Analyzer.java:163)
at org.jacoco.cli.internal.core.analysis.Analyzer.analyzeClass(Analyzer.java:135)
at org.jacoco.cli.internal.core.analysis.Analyzer.analyzeClass(Analyzer.java:158)
at org.jacoco.cli.internal.core.analysis.Analyzer.analyzeAll(Analyzer.java:195)
at org.jacoco.cli.internal.core.analysis.Analyzer.analyzeAll(Analyzer.java:228)
at org.jacoco.cli.internal.commands.Report.analyze(Report.java:110)
at org.jacoco.cli.internal.commands.Report.execute(Report.java:84)
at org.jacoco.cli.internal.Main.execute(Main.java:90)
at org.jacoco.cli.internal.Main.main(Main.java:105)
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 72
at org.jacoco.cli.internal.asm.ClassReader.<init>(ClassReader.java:200)
at org.jacoco.cli.internal.asm.ClassReader.<init>(ClassReader.java:180)
at org.jacoco.cli.internal.asm.ClassReader.<init>(ClassReader.java:166)
at org.jacoco.cli.internal.core.internal.instr.InstrSupport.classReaderFor(InstrSupport.java:280)
at org.jacoco.cli.internal.core.analysis.Analyzer.analyzeClass(Analyzer.java:108)
at org.jacoco.cli.internal.core.analysis.Analyzer.analyzeClass(Analyzer.java:133)
... 7 more
See #2162
Use of certain Value Classes leads to exceptions such
Caused by: java.lang.IllegalArgumentException
at org.jacoco.cli.internal.asm.ClassReader.readStackMapFrame(ClassReader.java:3364)
at org.jacoco.cli.internal.asm.ClassReader.readCode(ClassReader.java:2087)
at org.jacoco.cli.internal.asm.ClassReader.readMethod(ClassReader.java:1512)
at org.jacoco.cli.internal.asm.ClassReader.accept(ClassReader.java:745)
at org.jacoco.cli.internal.asm.ClassReader.accept(ClassReader.java:425)
Such classes should be excluded from report generation so that the report can be generated for other classes.
See #2164
References
JaCoCo version 0.8.15 can already be used with JDK 28 EA to measure coverage of code compiled for Java 27 and earlier. And we wanna believe that for such use-case no additional changes will be required.
However newer JaCoCo version is required to measure coverage of code compiled for Java 28 - #2162
We wanna believe that only above change will be enough to measure coverage for code that does not use preview features.
However for code that uses certain preview features, such as value classes, even more changes will most likely be required.
Coverage of code compiled for Java 27 and earlier when executed on JDK 28 EA
As proof JaCoCo 0.8.15 itself builds successfully with JDK 28 EA even without #2162:
Use of Java 28 classes from platform class loader
With JaCoCo 0.8.15 use of Java 28 classes from platform class loader leads to exceptions such as
that indicate inability to measure coverage of only mentioned class without any impacts on coverage measurement for other classes.
To get rid of such exceptions agent option
exclclassloadercan be usedSuch classes will be excluded by default in JaCoCo 0.8.16-SNAPSHOT - see #2152
Generation of coverage report for Java 28 class files
With JaCoCo 0.8.15 attempt to generate coverage report for Java 28 class files leads to
See #2162
Measurement of code coverage and generation of report for Value Classes (JEP 401)
Use of certain Value Classes leads to exceptions such
Such classes should be excluded from report generation so that the report can be generated for other classes.
See #2164
References