Bump the version baseline of apache/skywalking-graalvm-distro to v11.0.0

[linghengqian]

• Now that https://github.com/apache/skywalking/releases/tag/v11.0.0 has been released, there seems to be no reason to prevent https://github.com/apache/skywalking-graalvm-distro from updating from v10.4.0 to v11.0.0.
• I’m not sure if anyone in the community is currently working on a relevant PR, but I haven't found any related issues. Also, it’s a bit awkward that I currently don't have the time to test the main branch of https://github.com/apache/skywalking-graalvm-distro .

[wu-sheng]

It has not been done. It will take time when I or someone available.
Currently, ai sessionizer project is my focus.

[wu-sheng]

Many works are pending there. DSL management and debug may need to disabled and keep compatible for Horizon UI.
We can't do that in static compiling.

[linghengqian]

We can't do that in static compiling.

• I haven't yet tested the impact of Project Crema: Open World for Native Image oracle/graal#11327 on projects similar to apache/shardingsphere—specifically regarding features like Groovy scripting. However, -H:+RuntimeClassLoading does appear in https://github.com/oracle/graal/blob/vm-25.3.4.1/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/hub/RuntimeClassLoading.java .
• This requires some further investigation.

# For `version-fox/vfox`,
vfox install java@25.3.4.1-graalce

# Or for `sdkman/sdkman-cli`,
sdk install java 25.3.4.1-graalce

[wu-sheng]

We don't have groovy anymore since 10.4.0. We built DSL compiling process and runtime on our own now.

[linghengqian]

• If we simply need to use anonymous classes or lambda classes within a GraalVM Native Image, we can already use prefix matching in the GraalVM Reachability Metadata JSON; starting with GraalVM CE for JDK 25, defining the full class name is no longer required.

• This applies unless we are dealing with something like https://github.com/janino-compiler/janino .

[wu-sheng]

The baseline bump is up: apache/skywalking-graalvm-distro#31 moves the distro from 10.4.0 (via the 11.0.0-SNAPSHOT intermediate syncs) to the v11.0.0 release tag, adopts every new MAL/LAL/OAL rule (Airflow, BanyanDB so11y, Node.js/PHP runtime, iOS, mini-program, envoy-als-tcp) with upstream defaults, and adds e2e coverage for the new admin features. Native image (amd64/arm64) and the e2e matrix are running in CI.

An update on what I said above about DSL management/debugging in static compiling. It turned out better than "disable and keep compatible":

• DSL live debugging (SWIP-13) is fully supported in the native image, with no runtime class loading. The debug probes are a codegen-time decision (DSLDebugCodegenSwitch), so the distro's precompiler flips the same switch the JVM OAP flips at boot and the probes/gate holders are baked into the pre-compiled rule classes at build time. The upstream dsl-debugging module runs unchanged and only flips gates at runtime. All /dsl-debugging/* and /runtime/oal/* endpoints work with Horizon UI.
• DSL management is read-only. GET /runtime/rule/list, /runtime/rule/bundled and GET /runtime/rule are served from the raw rule sources bundled at build time, with the same payloads and X-Sw-* headers as the JVM OAP, so Horizon UI lists and opens every bundled rule (always BUNDLED). addOrUpdate/inactivate/delete/dump and /runtime/mal|lal/* return a structured HTTP 501, and Horizon UI degrades to its warning banner.

On -H:+RuntimeClassLoading (oracle/graal#11327, Project Crema), thanks @linghengqian for the pointer. I verified it with a PoC that runs the OAP's Javassist DSL pipeline (source -> bytecode -> defineClass -> execute) inside a native image:

• GraalVM CE 25.0.2: the image builds with the flag and defineClass of foreign bytecode succeeds, but reflective constructor lookup on the loaded class fails (NoSuchMethodException) and Lookup.defineClass reports "enclosing class is not supported yet". Not usable.
• GraalVM CE 25.3.4: the flag alone defines the class, but as soon as the loaded class calls into AOT-compiled code the process aborts with Unable to call AOT method ... not compiled because it was not seen as reachable. Consider using -H:Preserve=package=<pkg>. Runtime-loaded classes may only link to preserved AOT code.
  • -H:Preserve=all: every probe passes, including a full Javassist compile + define + run. Cost: build time 1 min -> 21.5 min, image 270 MB -> 840 MB (on the PoC image).
  • -H:Preserve=package=<app>,package=java.lang: passes as well at ~1 min / 279 MB, except anything using invokedynamic string concat (StringConcatFactory not preserved).
• Javassist additionally needs the .class bytes of every referenced JDK/OAP class at runtime (no jrt/jar access in the image), so those would have to be shipped as image resources.
• Runtime-loaded code is interpreted, not JIT-compiled, so hot-updated rules would run much slower than the pre-compiled ones.

So Crema can run the rule hot-update path, but it is still marked experimental, requires preserving every package a rule may touch (or paying the 3x size / 20x build time of Preserve=all), and the resulting rules are interpreted. Not something to ship in 0.4.0; worth revisiting once Crema is stable.

On the reachability-metadata prefix matching for lambdas/anonymous classes: that is not what blocks us. All the DSL classes are generated at build time and registered explicitly by the precompiler. The blocker for hot update is compiling new bytecode from a rule source at runtime, which is the same category as the janino case you mentioned.