3.31+ breaks fast-jar bundled with jpackage

[shepherd85]

Describe the bug

I upgraded from 3.30.5 -> 3.31.3, and my jpackage builds are no longer working due to classloader errors. I am building fast-jar, then bundling with jpackage.

Expected behavior

The application launches.

Actual behavior

Fast fail with this error:

Caused by: java.lang.ClassCastException: class io.quarkus.registry.ValueRegistry_xCLCDU8snsCILE1gjeVwq51pNh8_Synthetic_Bean cannot be cast to class io.quarkus.arc.InjectableBean (io.quarkus.registry.ValueRegistry_xCLCDU8snsCILE1gjeVwq51pNh8_Synthetic_Bean is in unnamed module of loader 'app'; io.quarkus.arc.InjectableBean is in unnamed module of loader io.quarkus.bootstrap.runner.RunnerClassLoader @69d9c55)
        at io.quarkus.arc.impl.ArcContainerImpl.<init>(ArcContainerImpl.java:141)
        at io.quarkus.arc.Arc.initialize(Arc.java:53)
        at io.quarkus.arc.runtime.ArcRecorder.initContainer(ArcRecorder.java:53)
        at io.quarkus.runner.recorded.ArcProcessor$initializeContainer643029769.deploy_0(Unknown Source)
        at io.quarkus.runner.recorded.ArcProcessor$initializeContainer643029769.deploy(Unknown Source)
        ... 8 more

How to Reproduce?

Using the attached reproducer, run:

> mvn package "-Pwindows,working"
> mvn package "-Pwindows,broken"

target/windows/working/working.exe runs 3.30.5,
target/windows/broken/broken.exe runs 3.31.3

test.zip

Output of uname -a or ver

No response

Output of java -version

openjdk version "25.0.2" 2026-01-20 LTS OpenJDK Runtime Environment Corretto-25.0.2.10.1 (build 25.0.2+10-LTS) OpenJDK 64-Bit Server VM Corretto-25.0.2.10.1 (build 25.0.2+10-LTS, mixed mode, sharing)

Quarkus version or git rev

3.31.3

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

Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937) Maven home: C:\Program Files\apache-maven-3.9.9 Java version: 25.0.2, vendor: Amazon.com Inc., runtime: C:\java\jdk25.0.2_10 Default locale: en_US, platform encoding: UTF-8 OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"

Additional information

No response

[shepherd85]

Found a solution for now: jpackage places all jars on the system classpath, breaking the fast-jar classloader.

[Application]
app.classpath=$APPDIR\quarkus-run.jar
app.mainclass=io.quarkus.bootstrap.runner.QuarkusEntryPoint

# removing all `app.classpath` lines from here down allows it to run
app.classpath=$APPDIR\app\test-application-1.0.jar

app.classpath=...removed for brevity, but every single jar under app/lib/**/* is listed individually...

# or, simply removing these two lines at a minimum allows it to run
app.classpath=$APPDIR\quarkus\generated-bytecode.jar
app.classpath=$APPDIR\quarkus\transformed-bytecode.jar

[JavaOptions]
java-options=-Djpackage.app-version=1.0
java-options=-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT
java-options=--add-opens=java.base/java.lang=ALL-UNNAMED
java-options=--enable-native-access=ALL-UNNAMED

At a minimum, removing generated-bytecode.jar and transformed-bytecode.jar from app.classpath allows the jpackage'd app to run. It does also run if I remove everything after the app.mainclass= line.

For now, I can workaround with post-processing the .cfg file. I don't know if there is a supported fix for this already, but being able to bundle with jpackage would be nice. JPackage is a must because I need to be able to load dynamic extensions, so native-image is a non-starter.

[geoand]

Can you try 3.32.0.CR1 please?

[shepherd85]

Can you try 3.32.0.CR1 please?

Same errors as the original issue, but the same workaround works - remove the generated-bytecode and transformed-bytecode jars from the jpackage-generated .cfg file, and it works.

[geoand]

Thanks for checking

[gsmet]

To be honest, what surprises me is that it was working with older versions.

@Ladicek @radcortez maybe it rings a bell?

[radcortez]

ValueRegistry was added here #51209, in 3.31.0, so maybe something specific with ValueRegistry is triggering the issue? Nothing comes to mind, but I'll try to have a look.

[geoand]

Do we have any news on this?

[gsmet]

TBH, I'm not really sure we can support with fast-jar a packaging that completely redefines the classpath.