11package datadog .compiler ;
22
3- import java .util .concurrent .Executor ;
4- import org .burningwave .core .assembler .StaticComponentContainer ;
5- import org .burningwave .core .function .ThrowingRunnable ;
6-
73public class CompilerModuleOpener {
84
95 /**
@@ -20,15 +16,19 @@ public class CompilerModuleOpener {
2016 * </ul>
2117 */
2218 public static void setup () {
23- try {
24- if ( StaticComponentContainer . JVMInfo . getVersion () >= 16 ) {
25- StaticComponentContainer . Modules . exportToAllUnnamed ( "jdk.compiler" );
26- }
27- // force classes to be loaded: https://github.com/burningwave/core/discussions/15
28- ThrowingRunnable . class . getClassLoader ();
29- Executor . class . getClassLoader ();
30- } catch ( Throwable e ) {
31- // ignore
19+ // On Java 26+, burningwave's StaticComponentContainer fails to initialize because its
20+ // transitive dependency (jvm-driver) uses a Class.forName0 signature that was removed
21+ // in JDK 26 (JEP 471/498). The failure prints a noisy stacktrace to stderr even though
22+ // the exception is caught. When running with the dd-trace-java agent, module exports are
23+ // already handled by CompilerModuleExporter via Instrumentation.redefineModule(), so
24+ // burningwave is not needed. For standalone usage, --add-exports flags must be provided
25+ // manually (see README).
26+ if ( Runtime . version (). feature () >= 26 ) {
27+ return ;
3228 }
29+ // Burningwave references are isolated in a separate class so that the JVM
30+ // class verifier does not resolve them when CompilerModuleOpener is loaded.
31+ // This prevents StaticComponentContainer.<clinit> from running on JDK 26+.
32+ BurningwaveModuleOpener .open ();
3333 }
3434}
0 commit comments