Quarkus main apps with opentelemetry are no longer buildable with ubi-quarkus-mandrel-builder-image:jdk-21

[rsvoboda]

Describe the bug

Quarkus main apps with opentelemetry are no longer buildable with ubi-quarkus-mandrel-builder-image:jdk-21

Error: An object of type 'com.sun.management.internal.OperatingSystemImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.

This happens after #53476 change cc @brunobat

Build with Java 25 based Mandrel works fine.

@gsmet I think CI is using exclusively Java 25 based runtimes, but maybe one set of PR jobs or daily run could use quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-21

Details from native image build:

1/8] Initializing...                                                                                    (3.8s @ 0.18GB)
 Java version: 21.0.10+7-LTS, vendor version: Mandrel-23.1.10.0-Final
 Graal compiler: optimization level: 2, target machine: armv8-a
 C compiler: gcc (redhat, aarch64, 8.5.0)
 Garbage collector: Serial GC (max heap size: 80% of RAM)
 8 user-specific feature(s):
 - com.oracle.svm.thirdparty.gson.GsonFeature
 - io.quarkus.opentelemetry.runtime.graal.UnsignedFeature
 - io.quarkus.runner.Feature: Auto-generated class by Quarkus from the existing extensions
 - io.quarkus.runtime.graal.DisableLoggingFeature: Adapts logging during the analysis phase
 - io.quarkus.runtime.graal.JVMChecksFeature
 - io.quarkus.runtime.graal.SkipConsoleServiceProvidersFeature: Skip unsupported console service providers when quarkus.native.auto-service-loader-registration is false
 - org.eclipse.angus.activation.nativeimage.AngusActivationFeature
 - org.eclipse.angus.mail.nativeimage.AngusMailFeature
------------------------------------------------------------------------------------------------------------------------
 5 experimental option(s) unlocked:
 - '-H:+AllowFoldMethods' (origin(s): command line)
 - '-H:BuildOutputJSONFile' (origin(s): command line)
 - '-H:-UseServiceLoaderFeature' (origin(s): command line)
 - '-H:+GenerateBuildArtifactsFile' (origin(s): command line)
 - '-H:AddOpens' (alternative API option(s): --add-opens java.base/java.lang=ALL-UNNAMED; origin(s): command line)
------------------------------------------------------------------------------------------------------------------------
Build resources:
 - 5.33GB of memory (59.3% of 9.00GB system memory, set via '-Xmx6g')
 - 6 thread(s) (100.0% of 6 available processor(s), determined at start)
java.lang.ClassNotFoundException: io.opentelemetry.instrumentation.runtimemetrics.java8.internal.CpuMethods
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageClassLoader.loadClass(NativeImageClassLoader.java:637)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:536)
	at java.base/java.lang.Class.forName(Class.java:515)
	at io.quarkus.runner.Feature.beforeAnalysis(Unknown Source)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.lambda$runPointsToAnalysis$9(NativeImageGenerator.java:773)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.java:90)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.runPointsToAnalysis(NativeImageGenerator.java:773)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:592)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:550)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:538)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:727)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.start(NativeImageGeneratorRunner.java:142)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:97)
[2/8] Performing analysis...  [*****]                                                                   (27.6s @ 1.47GB)
   19,983 reachable types   (89.4% of   22,340 total)
   32,625 reachable fields  (65.1% of   50,113 total)
  107,673 reachable methods (61.7% of  174,645 total)
    6,525 types, 2,118 fields, and 17,311 methods registered for reflection
       62 types,    67 fields, and    55 methods registered for JNI access
        4 native libraries: dl, pthread, rt, z

Error: Unsupported features in 3 methods
Detailed message:
Error: An object of type 'com.sun.management.internal.OperatingSystemImpl' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1) If it is intended that objects of type 'com.sun.management.internal.OperatingSystemImpl' are persisted in the image heap, add

    '--initialize-at-build-time=com.sun.management.internal.OperatingSystemImpl'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'com.sun.management.internal.OperatingSystemImpl' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use

    '--trace-object-instantiation=com.sun.management.internal.OperatingSystemImpl'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

Expected behavior

Native image to be produced

Actual behavior

Native image build fails

How to Reproduce?

• Build lates quarkus main
• Clone https://github.com/quarkus-qe/quarkus-test-suite
• Run mvn clean verify -Dnative -f monitoring/opentelemetry -Dquarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-21

Output of uname -a or ver

No response

Output of java -version

No response

Mandrel or GraalVM version (if different from Java)

quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-21

Quarkus version or git rev

No response

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

No response

Additional information

No response

[quarkus-bot]

/cc @Karm (native-image), @brunobat (opentelemetry), @galderz (native-image), @radcortez (opentelemetry), @zakkak (native-image)

[brunobat]

Strange because the native tests did pass... Will take a look.

[gsmet]

@gsmet I think CI is using exclusively Java 25 based runtimes, but maybe one set of PR jobs or daily run could use quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-21

My personal position on this is that we should only support one version of the builder, and that would be 25.
Native image is very different from "let's use a Java 21 JDK", which I think we should still support.

Now, that's a personal position, I don't know exactly what was decided.

[rsvoboda]

Strange because the native tests did pass... Will take a look.

CI uses Java 25 based Mandrel, this fails with Java 21 based Mandrel

My personal position on this is that we should only support one version of the builder, and that would be 25.

I don't mind that approach, the thing is that there is no clear communication on https://quarkus.io/ around Mandrel version which should be used.
quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-21 is actively maintained, although it's probably more because of 3.27 LTS, but it's our internal knowledge

cc @cescoffier @maxandersen about the one Mandrel/GraalVM version topic

[brunobat]

Will wait for feedback to see if I need to fix the build for jdk21, but if I do, the CI should be prepared to test it or this will happen again.

[rsvoboda]

Who needs to make that call?

[rsvoboda]

Currently both Java 21 and Java 25 based Mandrel builder images can be used and were working fine before @brunobat changes. Please look into fixing it. I see it as regression. Maybe @Karm @zakkak @jerboaa can hint something.

About "just one Mandrel version", I think this will be for a longer discussion. Right now we were just talking about Guillaume's preference and my position to it.

[jerboaa]

I can have a look tomorrow.

Will wait for feedback to see if I need to fix the build for jdk21, but if I do, the CI should be prepared to test it or this will happen again.

If this is reproducible with quarkus native integration tests, then we have weekly CI for that on Mandrel for JDK 21. We'll keep testing of the JDK 21 stack until about end of 2026. After that it'll likely be best effort only.

[jerboaa]

https://github.com/graalvm/mandrel/actions/runs/24198678847 is a mandrel build of 23.1 (JDK 21 based) that builds quarkus main and runs native integration tests. Lets see if that surfaces there as well. It was fine last week, which matches what this issue says.

[gsmet]

I discussed it with @zakkak a few times and tbh I'm not convinced it's a good use of our time to support multiple native builder versions for a given version of Quarkus.

Now, maybe this particular issue will be easy to solve but there might be others later and each requires some expertise.

Again, that's just my humble opinion - and it's not my time - but my intuition is that this time and expertise might be best spent elsewhere.

[jerboaa]

Basic native integration tests using otel don't seem to reproduce this. It needs the beefier QE app. And it looks to be aarch64 too.

Graal compiler: optimization level: 2, target machine: armv8-a
C compiler: gcc (redhat, aarch64, 8.5.0)

Will keep that one on the back-burner.

[maxandersen]

Just to confirm - this is not limiting users building jvm 17/21 - it's just about what builder image used for native image step ?

Asking as wasn't one of main reasons of working with various builder images also about which ubi distro it needs ?