ClassTooLargeException in JacocoProcessor during instrumentation

[dagrammy]

Describe the bug

Hello everyone,

I'm not sure if this problem belongs here or https://github.com/quarkiverse/quarkus-amazon-services.

We have updated our project to Quarkus 3.25. There is a problem with Jacoco and the AWS services, more precisely the DefaultSsmAsyncClient.

During instrumentation there is a ClassTooLargeException concerning DefaultSsmAsyncClient in the quarkus JacocoProcessor

Stack trace (complete stack trace s. readme of reproducer repo)

Caused by: java.lang.RuntimeException: java.io.IOException: Error while instrumenting software.amazon.awssdk.services.ssm.DefaultSsmAsyncClient with JaCoCo 0.8.13.202504020838/78d5eff.
	at io.quarkus.jacoco.deployment.JacocoProcessor$1.apply(JacocoProcessor.java:93)
	at io.quarkus.jacoco.deployment.JacocoProcessor$1.apply(JacocoProcessor.java:83)
	at io.quarkus.deployment.steps.ClassTransformingBuildStep.transformClass(ClassTransformingBuildStep.java:350)
	at io.quarkus.deployment.steps.ClassTransformingBuildStep$2.call(ClassTransformingBuildStep.java:238)
	at io.quarkus.deployment.steps.ClassTransformingBuildStep$2.call(ClassTransformingBuildStep.java:225)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	... 7 more
Caused by: java.io.IOException: Error while instrumenting software.amazon.awssdk.services.ssm.DefaultSsmAsyncClient with JaCoCo 0.8.13.202504020838/78d5eff.
	at org.jacoco.core.instr.Instrumenter.instrumentError(Instrumenter.java:161)
	at org.jacoco.core.instr.Instrumenter.instrument(Instrumenter.java:111)
	at io.quarkus.jacoco.deployment.JacocoProcessor$1.apply(JacocoProcessor.java:87)
	... 12 more
Caused by: org.objectweb.asm.ClassTooLargeException: Class too large: software/amazon/awssdk/services/ssm/DefaultSsmAsyncClient
	at org.objectweb.asm.ClassWriter.toByteArray(ClassWriter.java:616)
	at org.jacoco.core.instr.Instrumenter.instrument(Instrumenter.java:92)
	at org.jacoco.core.instr.Instrumenter.instrument(Instrumenter.java:109)
	... 13 more

I also tried to add the class to quarkus.jacoco.excludes, but this config property seems only to exclude classes from the report.

Expected behavior

The build is successful and Jacoco report generated.

Actual behavior

The build fails.

How to Reproduce?

Clone https://github.com/dagrammy/jacoco-ssm-reproducer and run ./gradlew build.

Output of uname -a or ver

Darwin 23.4.0 Darwin Kernel Version 23.4.0: Wed Feb 21 21:44:54 PST 2024; root:xnu-10063.101.15~2/RELEASE_ARM64_T6030 arm64

Output of java -version

OpenJDK Runtime Environment GraalVM CE 21.0.2+13.1 (build 21.0.2+13-jvmci-23.1-b30)

Quarkus version or git rev

3.25.0

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

Gradle 8.14

Additional information

No response

[geoand]

Thanks for reporting, unfortunately there is nothing we can do here...

This sounds like a Jacoco bug TBH

[dagrammy]

Hi @geoand ,

Thanks for your feedback. I also see that this is not a Quarkus problem. However, there is probably nothing Jacoco can do about it either, e.g. jacoco/jacoco#1653.

There is also a bug report in the AWS SDK aws/aws-sdk-java-v2#6234.
The workaround is usually to exclude the class from Jacoco by configuration

However, this is currently not possible in the JacocoProcessor.

quarkus/test-framework/jacoco/deployment/src/main/java/io/quarkus/jacoco/deployment/JacocoProcessor.java

Line 80 in 0404a0c

transformers.produce(

I could possibly make a CR to use the excludes config if it would be ok.

[geoand]

Sure, that sounds reasonable

[gsmet]

I have a few questions here:

• should we catch a ClassTooLargeException and just not instrument the class in this case? And log a warning.
• I'm surprised we instrument all the classes of all the libraries. I would have expected we would measure the coverage of only the application classes? But I'm probably missing something?

BTW, these questions don't prevent us from adding a way to ignore a class (or maybe even an entire archive).

[gsmet]

I'm surprised we instrument all the classes of all the libraries. I would have expected we would measure the coverage of only the application classes? But I'm probably missing something?

@geoand I would be interested in your feedback on this question.

[geoand]

That's probably what we should be doing

[gsmet]

@dagrammy are you able to test a PR and see if the test coverage is still fine?

[gsmet]

Reopening as I think there is more to it.