Stork related classes initialized in Quarkus 3.20 with rest client

[rsvoboda]

Describe the bug

Stork related classes (io/quarkus/runner/recorded/SmallRyeStorkProcessor) are initialized in Quarkus 3.20 application with rest client, while stork is not being used

I was playing with new AsyncProfiler 4 and noticed that Quarkus 3.20 has Stork related classes in CPU FlameGraph. I was using https://github.com/quarkus-qe/quarkus-startstop/blob/main/app-full-microprofile/pom.xml application

I didn't see Stork related classes when using Quarkus 3.15.4 or 3.21.2. Quarkus 3.20 is LTS, thus reporting the issue.

Expected behavior

No Stork related classes get initialized as it's not actively used

Actual behavior

Stork classes get initialized

How to Reproduce?

git clone https://github.com/quarkus-qe/quarkus-startstop

wget https://github.com/async-profiler/async-profiler/releases/download/v4.0/async-profiler-4.0-macos.zip
unzip -q async-profiler-4.0-macos.zip
ASYNC_PROFILER=$PWD/async-profiler-4.0-macos

build () {
  QUARKUS_VERSION=$1
  mvn clean package -f /Users/rsvoboda/git/quarkus-startstop/app-full-microprofile -Dquarkus.version=${QUARKUS_VERSION}
  rm -rf quarkus-app-${QUARKUS_VERSION}
  mv /Users/rsvoboda/git/quarkus-startstop/app-full-microprofile/target/quarkus-app quarkus-app-${QUARKUS_VERSION}
}
startupCPU () {
  QUARKUS_VERSION=$1
  java -agentpath:${ASYNC_PROFILER}/lib/libasyncProfiler.dylib=start,event=cpu,file=startup-profile-cpu-${QUARKUS_VERSION}.html -jar quarkus-app-${QUARKUS_VERSION}/quarkus-run.jar &
  PID=$!
  sleep 3 && kill $PID
}

build 3.20.0
startupCPU 3.20.0

build 3.15.4
startupCPU 3.15.4

build 3.21.2
startupCPU 3.21.2

open startup*.html

Output of uname -a or ver

macOS

Output of java -version

Java 21

Quarkus version or git rev

Quarkus 3.20.0

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

No response

Additional information

No response

[quarkus-bot]

/cc @aureamunoz (stork), @cescoffier (rest-client,stork), @geoand (rest-client)

[cescoffier]

I don't think we changed something related to Stork but I need to check. Now, Stork can be used at runtime (programmatically) so it would need to be initialized - what's surprising is that it was not before.

[rsvoboda]

And it's also not in latest 3.21.2 🤷‍♂️

[geoand]

@rsvoboda I see the exact same behavior in 3.20 and 3.21 and from what I can tell, this is the proper behavior as REST Client depends on Stork.

[rsvoboda]

@geoand can you share your flame graphs? Here are mine: Archive.zip (html is not allowed to be attached ...)

Search using .*Stork.* shows hit just in 3.20 file, not in the others.

About Stork being a dependency of REST Client ... yup, I'm aware of it. I can't say I'm a fan of it though :)

[geoand]

@rsvoboda I didn't use a flamegraph, I used a debugger

[gsmet]

I created #47428 in case it makes sense...

[gsmet]

I went with another approach here: #47435 .

I agree with @rsvoboda than having Stork as a hard dependency of the REST Client and initializing it for every application using the REST Client is something we should fix.

FWIW, it's also a hard dependency of the gRPC extension, I will have a quick look at if we can improve things there here or not.