RuntimeException using VirtualThreads with Jacoco

[HiddenSplioGuy]

Describe the bug

Building a quarkus 2.16.3 app using Virtual threads on JDK 19 I came up with the following error on runtime :

Method xxx of class 'XXX' uses @RunOnVirtualThread but the target JDK version doesn't support virtual threads. Please configure your build tool to target Java 19 or above.

I know my project is built correctly using the JDK19 because I checked the .class major version and it was correctly set to 63.

Expected behavior

No error.

Actual behavior

It seems like Quarkus pickups the first class file it found in the build directory to determine the project majorVersion.

I have run the compiledJavaVersion function on my built files and it always picked up AgentJar.class file (From Jacoco) with a majorVersion set to 49.
Here is another Jacoco class getting picked up by your algo after setting classDumpDir with :

classDumpDir = layout.buildDirectory.dir('jacoco/classpathdumps').get().asFile

KryoException.a0b9661061bc7653.class
majorFound : 49

How to Reproduce?

• Clone this project
• Execute the project test in a gitlab runner environment (I use https://www.npmjs.com/package/gitlab-ci-local#installation)
• gradle build --info to see the error in the gitlab runner env.
• It works flawlessly locally

Output of uname -a or ver

Linux 91d7275ab5b8 5.15.79.1-microsoft-standard-WSL2 #1 SMP Wed Nov 23 01:01:46 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk version "19.0.2" 2023-01-17
OpenJDK Runtime Environment Temurin-19.0.2+7 (build 19.0.2+7)
OpenJDK 64-Bit Server VM Temurin-19.0.2+7 (build 19.0.2+7, mixed mode, sharing)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.16.3

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

8.0.1

Additional information

Is quarkus-jacoco using the latest Jacoco version with jdk19 class support ?
https://github.com/jacoco/jacoco/releases

[geoand]

Can you provide a sample application I can use to debug?

Thanks

[HiddenSplioGuy]

Hi @geoand ,

I added a reproducer,

Thank you.

[geoand]

Does one really need to execute it in a gitlab environment in order to see the issue?

[HiddenSplioGuy]

I did not manage to reproduce the issue running the project locally.
So I'd say yes.

[geoand]

I see, thanks.

[geoand]

I'll try and have a look this week

[geoand]

Hm.. Without being able to add a debbuger to this, it's very hard to figure ouw what's going on. I have opened #31510 to add more logging

[HiddenSplioGuy]

I personally used this small project which copycats the compiledJavaVersion function to debug this.
I just compiled the project into a jar and put in the repo which then allowed me to debug the behaviour of the function in the gitlab env.

[manuito]

Hi,

I had the same issue on another project, once again only if jacoco is integrated.

After investigation, the faulty component is https://github.com/quarkusio/quarkus/blob/main/core/deployment/src/main/java/io/quarkus/deployment/steps/CompiledJavaVersionBuildStep.java which define the javaVersion used at https://github.com/quarkusio/quarkus/blob/main/independent-projects/resteasy-reactive/common/processor/src/main/java/org/jboss/resteasy/reactive/common/processor/EndpointIndexer.java#L831 to validate @RunOnVirtualThread compatibility.

To get the target javaVersion, it walks through build content and detect it from the first found .class. This seems to induce a lot of issues :

• File walk is filesystem dependent : the order of listed file could depend on the natural sort order of the file system. Behavior could change between 2 different OS / FS. I have an example with jacoco agent entrypoint (ex build/tmp/.cache/expanded/zip_0bd0851504e6286cb5fc6f37a81e25cc/org/jacoco/agent/AgentJar.class) being the 1st loaded file on zfs but not on ext4, for same project, and same build stack. That's why this pb was first detected as an incompatibility with jacoco (& difficult to reproduce). Usually we should avoid any behavior based on file listing of class files.
• The "maximum" javaVersion should be used here instead of the 1st one. Yes, it will have dramatic impact on perf (because we have to check all class files, so we shouldn't do that... But technically it would be more correct this way because here we are looking for a constraint on java version : the good one is the "max one"
• There is no option to setup the javaVersion from the build options. Nothing is available for now on BuildSystemTargetBuildItem.buildSystemProps. Maybe the source and target java version from build tool should be shared here and used as the default java version definition

I know that detecting "automatically" the build target can be complex, and I'm out of idea for now on how to improve it. But this problem still exists and adding the use of build tool java version props could help to avoid it in most cases.

Regards.

[mjedwabn]

Ugly w/a:

build.gradle:

task quarkus31375wa(type: JavaCompile) {
    source = 'src/fixes/java'
    include 'AFixForQuarkus31375.java'
    classpath = sourceSets.main.compileClasspath
    destinationDir = new File('build/z')
}

src/fixes/java/AFixForQuarkus31375.java:

class AFixForQuarkus31375 {
}

then just include quarkus31375wa step before test, ex.
gradle clean quarkus31375wa test

[AntonFagerberg]

We're experiencing the same issue but on Azure DevOps (with Java 21).
Works fine locally and on Azure DevOps after disabling the Jacoco gradle plugin.

[chwalker-fadv]

Any update on when this will be fixed?

[gsmet]

@geoand have you seen this comment: #31375 (comment) ?

It looks interesting.

[geoand]

I have not. I'll take a look at some point

[gsmet]

I think this is probably this problem occurring: #42884 that will be fixed by #42897.

[geoand]

Thanks

I'm totally out of that loop, so can't really comment now.