The native image fails when running with virtual threads enabled

[gayanper]

Actual behavior (the bug)
The native image fails when running with virtual threads enabled

Expected behavior
The native image should not fail when running with virtual threads enabled

To Reproduce

    public static void main(String[] args) {
        Javalin.create(cfg -> {
            cfg.useVirtualThreads = true;
        }).get("/hello",  App:sayHello).start(8080);
    }

create the server with the above configuration

Additional context

GraalVM Information

 Java version: 21+37-LTS, vendor version: Liberica-NIK-23.1.0-1
 Graal compiler: optimization level: 0, target machine: armv8-a
 C compiler: cc (apple, arm64, 15.0.0)
 Garbage collector: Serial GC (max heap size: 80% of RAM)

Stacktrace

2024-03-13 12:22:53.546 [main] INFO  io.javalin.Javalin - Starting Javalin ...
2024-03-13 12:22:53.546 [main] INFO  org.eclipse.jetty.server.Server - jetty-11.0.20; built: 2024-01-29T21:04:22.394Z; git: 922f8dc188f7011e60d0361de585fd4ac4d63064; jvm 21+37-LTS
2024-03-13 12:22:53.549 [main] INFO  o.e.j.s.s.DefaultSessionIdManager - Session workerName=node0
2024-03-13 12:22:53.550 [main] INFO  o.e.j.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler@19f0a8de{/,null,AVAILABLE}
Exception in thread "main" java.lang.NoSuchMethodError: java.lang.Thread$Builder$OfVirtual.unstarted(java.lang.Runnable)
        at org.graalvm.nativeimage.builder/com.oracle.svm.core.methodhandles.Util_java_lang_invoke_MethodHandleNatives.resolve(Target_java_lang_invoke_MethodHandleNatives.java:335)
        at org.graalvm.nativeimage.builder/com.oracle.svm.core.methodhandles.Util_java_lang_invoke_MethodHandle.invokeInternal(Target_java_lang_invoke_MethodHandle.java:181)
        at java.base@21/java.lang.invoke.MethodHandle.invokeBasic(MethodHandle.java:98)
        at org.graalvm.nativeimage.builder/com.oracle.svm.core.methodhandles.MethodHandleIntrinsicImpl.execute(MethodHandleIntrinsicImpl.java:179)
        at org.graalvm.nativeimage.builder/com.oracle.svm.core.methodhandles.Util_java_lang_invoke_MethodHandle.invokeInternal(Target_java_lang_invoke_MethodHandle.java:186)
        at java.base@21/java.lang.invoke.MethodHandle.invokeBasic(MethodHandle.java:98)
        at java.base@21/java.lang.invoke.LambdaForm$NamedFunction.invokeWithArguments(LambdaForm.java:96)
        at java.base@21/java.lang.invoke.LambdaForm.interpretName(LambdaForm.java:959)
        at java.base@21/java.lang.invoke.LambdaForm.interpretWithArguments(LambdaForm.java:936)
        at java.base@21/java.lang.invoke.MethodHandle.invokeBasic(MethodHandle.java:105)
        at java.base@21/java.lang.invoke.MethodHandle.invokeBasic(MethodHandle.java:0)
        at java.base@21/java.lang.invoke.Invokers$Holder.invoke_MT(Invokers$Holder)
        at io.javalin.util.ReflectiveVirtualThreadBuilder.unstarted(ConcurrencyUtil.kt:159)
        at io.javalin.util.NamedVirtualThreadFactory.newThread(ConcurrencyUtil.kt:133)
        at java.base@21/java.util.concurrent.ThreadPerTaskExecutor.newThread(ThreadPerTaskExecutor.java:219)
        at java.base@21/java.util.concurrent.ThreadPerTaskExecutor$ThreadBoundFuture.<init>(ThreadPerTaskExecutor.java:336)
        at java.base@21/java.util.concurrent.ThreadPerTaskExecutor.submit(ThreadPerTaskExecutor.java:285)
        at java.base@21/java.util.concurrent.ThreadPerTaskExecutor.submit(ThreadPerTaskExecutor.java:293)
        at io.javalin.util.LoomUtil$LoomThreadPool.execute(ConcurrencyUtil.kt:62)
        at org.eclipse.jetty.io.SelectorManager.execute(SelectorManager.java:139)
        at org.eclipse.jetty.io.ManagedSelector.doStart(ManagedSelector.java:119)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
        at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:171)
        at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:121)
        at org.eclipse.jetty.io.SelectorManager.doStart(SelectorManager.java:256)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
        at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:171)
        at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
        at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:367)
        at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:75)
        at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:228)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
        at org.eclipse.jetty.server.Server.doStart(Server.java:428)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:93)
        at io.javalin.jetty.JettyServer.start(JettyServer.kt:93)
        at io.javalin.Javalin.start(Javalin.java:123)
        at App.main(App.java:18)
        at java.base@21/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH)

[tipsy]

@gayanper is this only when using GraalVM?

[gayanper]

This is when running the native image built by the distribution of graalvm i have mentioned.

I think its due to reflection access to enable virtual threads as I suspect