Actuator /info endpoint fails in Java 25 Native Image (VirtualThreadSchedulerMXBean support)

[cmdjulian]

I am encountering an issue when running a Spring Boot 4.0.1 application built as a GraalVM Native Image using Java 25.

When accessing the /actuator/info endpoint, the application throws a HttpMessageNotWritableException. The root cause is an IllegalArgumentException stating that jdk.management.VirtualThreadSchedulerMXBean is not a platform management interface.

This occurs despite the recent changes in PR #43594, which added ProcessInfoContributorRuntimeHints to register this class for reflection. It appears that while the class is reflectively available, the ManagementFactory in the native image environment does not recognize it as a valid Platform MXBean.

Spring Boot Version: 4.0.1
Java Version: Java 25 (Oracle GraalVM 25+37.1)
Build System: Gradle (Kotlin DSL)

Steps to reproduce:
I have created a minimal reproducer repository.

1. Clone the repository: https://github.com/cmdjulian/process-info-bug
2. Build the native image:

./gradlew nativeCompile

3. Run the application:

./build/native/nativeCompile/demo

4. Query the endpoint:

curl -i http://localhost:8090/actuator/info

Observed Error:
The request fails with a 500 Internal Server Error. The logs show:

2026-01-13T14:25:44.338+01:00 ERROR ... 500 Server Error for HTTP GET "/actuator/info"
...
Caused by: java.lang.IllegalArgumentException: jdk.management.VirtualThreadSchedulerMXBean is not a platform management interface
    at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.management.ManagementSupport.getPlatformMXBean(ManagementSupport.java:142) ~[na:na]
    at java.management@25/java.lang.management.ManagementFactory.getPlatformMXBean(ManagementFactory.java:56) ~[demo:na]
    at org.springframework.boot.info.ProcessInfo.getVirtualThreads(ProcessInfo.java:106) ~[demo:4.0.1]

Analysis:
The feature was introduced in PR #43594, which added the getVirtualThreads() method to ProcessInfo and included ProcessInfoContributorRuntimeHints to register jdk.management.VirtualThreadSchedulerMXBean for reflection.

However, the exception comes from ManagementFactory.getPlatformMXBean(Class), which validates if the requested class is a known platform MXBean. In a standard JVM, this works for VirtualThreadSchedulerMXBean in Java 24/25. In the Native Image (SubstrateVM), it seems this new MXBean is not automatically registered in the internal management support lookup, or ManagementFactory requires specific GraalVM configuration/substitution to recognize it, beyond just standard reflection hints.

Workaround Attempts:

• --enable-monitoring=all: Applied, but did not resolve the issue.
• RuntimeHints: The existing hints from PR Add info contributor support for JDK 24's VirtualThreadSchedulerMXBean #43594 are present, but do not satisfy the ManagementFactory check.

[wilkinsona]

This looks like a GraalVM bug to me.

package com.example.demo;

import java.lang.management.ManagementFactory;
import jdk.management.VirtualThreadSchedulerMXBean;

public class DemoApplication {
	
	public static void main(String[] args) {
		System.out.println(ManagementFactory.getPlatformMXBean(VirtualThreadSchedulerMXBean.class));
	}
}

This app fails in the same way when built as a native image without involving Spring Boot at all:

Exception in thread "main" java.lang.IllegalArgumentException: jdk.management.VirtualThreadSchedulerMXBean is not a platform management interface
        at org.graalvm.nativeimage.builder/com.oracle.svm.core.jdk.management.ManagementSupport.getPlatformMXBean(ManagementSupport.java:142)
        at java.management@25.0.1/java.lang.management.ManagementFactory.getPlatformMXBean(ManagementFactory.java:56)
        at com.example.demo.DemoApplication.main(DemoApplication.java:9)
        at java.base@25.0.1/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH)

I've opened oracle/graal#12802. In the meantime, we should probably be more defensive in how we retrieve the MXBean.

[cmdjulian]

Is there something a user could do or something from Boots side, to prevent the /info endpoint crashing? Unfortunately we had to disable it to keep our monitoring usable to not error out on the 500ers.
As the detection if the endpoint participates is happening during build time, we also had to re-compile our application and re-deploy it with the disabled endpoint which is not a very nice dx.
It would be nice if one could simply disable the threading metrics somehow via env var dynamically during runtime.

[wilkinsona]

Is there something a user could do or something from Boots side, to prevent the /info endpoint crashing?

On the user side, rather than disabling the whole info endpoint, you could stop setting management.info.process.enabled to true.

On the Boot side, we'll make ProcessInfo more robust so that any exceptions when trying to interact with VirtualThreadSchedulerMXBean are caught with the virtual threads info then being omitted from the response.