3.6.0 regression: java.lang.NoClassDefFoundError: Could not initialize class org.apache.maven.surefire.api.report.StackWalkerStrategy

[wendigo]

Affected version

3.6.0

Bug description

[ERROR] java.lang.NoClassDefFoundError: Could not initialize class org.apache.maven.surefire.api.report.StackWalkerStrategy
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There was an error in the forked process
[ERROR] java.lang.NoClassDefFoundError: Could not initialize class org.apache.maven.surefire.api.report.StackWalkerStrategy
[ERROR] 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:708)
[ERROR] 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:523)
[ERROR] 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:323)
[ERROR] 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:287)
[ERROR] 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1474)
[ERROR] 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1246)
[ERROR] 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:1082)
[ERROR] 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:126)
[ERROR] 	at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:328)
[ERROR] 	at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:316)
[ERROR] 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
[ERROR] 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:174)
[ERROR] 	at org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:75)
[ERROR] 	at org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:162)
[ERROR] 	at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
[ERROR] 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159)
[ERROR] 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:105)
[ERROR] 	at io.takari.maven.builder.smart.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:206)
[ERROR] 	at io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:71)
[ERROR] 	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
[ERROR] 	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:328)
[ERROR] 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
[ERROR] 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
[ERROR] 	at java.base/java.lang.Thread.run(Thread.java:1474)```

[wendigo]

Root cause, confirmed via bytecode analysis + full stack trace (Caused by: chain):

StackWalkerStrategy.<clinit> calls Thread.currentThread().getContextClassLoader() and passes it to ReflectionUtils.tryLoadClass(ClassLoader, String):

public static Class<?> tryLoadClass(ClassLoader loader, String name) {
    try {
        return loader.loadClass(name);  // NPE if loader == null
    } catch (NoClassDefFoundError | ClassNotFoundException e) {
        return null;
    }
}

This only catches NoClassDefFoundError/ClassNotFoundException — not NullPointerException. When the current thread's context classloader happens to be null at the moment StackWalkerStrategy is first touched, tryLoadClass throws an uncaught NPE, which propagates out of <clinit> as ExceptionInInitializerError, permanently poisoning the class for the rest of the JVM fork's lifetime — every subsequent reference (from any thread, any test) then fails with NoClassDefFoundError: Could not initialize class ...StackWalkerStrategy.

Full first-occurrence trace we captured:

Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.NullPointerException [in thread "main"]
	at org.apache.maven.surefire.api.util.ReflectionUtils.tryLoadClass(ReflectionUtils.java:152)
	at org.apache.maven.surefire.api.report.StackWalkerStrategy.<clinit>(StackWalkerStrategy.java:60)
	at org.apache.maven.surefire.api.report.StackTraceProvider.getStack(StackTraceProvider.java:107)
	at org.apache.maven.surefire.api.report.TestOutputReportEntry.<init>(TestOutputReportEntry.java:52)
	...
	at jakarta.validation.Validation$ProviderSpecificBootstrapImpl.configure(Validation.java:214)

In our case the trigger is Jakarta Bean Validation's provider bootstrap (Validation$ProviderSpecificBootstrapImpl.configure()), which is known to temporarily swap/clear the thread's context classloader while doing its ServiceLoader-based provider discovery — a fairly common pattern in JVM libraries (also seen with ForkJoinPool.commonPool() worker threads, which have a null TCCL by design since JDK 9). Any first captured console write racing that window crashes the whole fork.

Confirmed this is a 3.6.0-only regression: the exact same reproduction passes cleanly on 3.5.6 (-Ddep.plugin.surefire.version=3.5.6), with no code changes — same log line fires first, no crash.

Minimal fix: catch RuntimeException (or at least NullPointerException) alongside NoClassDefFoundError/ClassNotFoundException in ReflectionUtils.tryLoadClass, so a null/broken classloader just disables the fast StackWalker-based path (AVAILABLE = false) instead of poisoning the class for the whole fork.

[wendigo]

cc @slachiewicz

[slawekjaranowski]

We hit the same regression from a different direction. Two things to add: a minimal deterministic reproducer, and a second, much more confusing failure mode.

Minimal reproducer

No Jakarta Validation, no ForkJoinPool, no race — just a thread with a null context class loader writing one line:

import org.junit.jupiter.api.Test;

class NullTcclPrintTest {

    @Test
    void printFromThreadWithNullContextClassLoader() throws Exception {
        Throwable[] failure = new Throwable[1];
        Thread t = new Thread(() -> {
            try {
                System.err.println("hello from null-TCCL thread");
            } catch (Throwable e) {
                failure[0] = e;
            }
        });
        t.setContextClassLoader(null);
        t.start();
        t.join();
        if (failure[0] != null) {
            throw new AssertionError("println failed", failure[0]);
        }
    }
}

Plain JUnit 5 project, nothing else needed. Fails on 3.6.0, passes on 3.5.6:

Caused by: java.lang.ExceptionInInitializerError
	at org.apache.maven.surefire.api.report.StackTraceProvider.getStack(StackTraceProvider.java:107)
	at org.apache.maven.surefire.api.report.TestOutputReportEntry.<init>(TestOutputReportEntry.java:52)
	at org.apache.maven.surefire.api.report.TestOutputReportEntry.<init>(TestOutputReportEntry.java:63)
	at org.apache.maven.surefire.api.report.TestOutputReportEntry.stdErrln(TestOutputReportEntry.java:132)
	at org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:116)
	at NullTcclPrintTest.lambda$printFromThreadWithNullContextClassLoader$0(NullTcclPrintTest.java:10)
	at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.NullPointerException: Cannot invoke "java.lang.ClassLoader.loadClass(String)" because "classLoader" is null
	at org.apache.maven.surefire.api.util.ReflectionUtils.tryLoadClass(ReflectionUtils.java:152)
	at org.apache.maven.surefire.api.report.StackWalkerStrategy.<clinit>(StackWalkerStrategy.java:60)

Reproduces with forkCount=1 and forkCount=0, and with useSystemClassLoader both true and false.

Second failure mode: dynamically attached JVM agents

This one does not surface as a StackWalkerStrategy error at all, which makes it hard to trace back here.

Our case is a Reactor BlockHound test (BlockHound.install() in @BeforeAll) on JDK 21:

1. BlockHound.install() attaches a Byte Buddy agent to the running JVM.
2. On JDK 9+ the JVM prints WARNING: A Java agent has been loaded dynamically ... from
   sun.instrument.InstrumentationImpl.<init>, running on the Attach Listener thread — whose
   context class loader is null by design.
3. That write goes through ConsoleOutputCapture$ForwardingPrintStream and throws
   ExceptionInInitializerError as above.
4. The exception escapes the InstrumentationImpl constructor, so the JVM aborts agent loading:

*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message
    call constructor on InstrumentationImpl failed at src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 526
*** java.lang.instrument ASSERTION FAILED ***: "success" with message
    createInstrumentationImpl failed at src/java.instrument/share/native/libinstrument/InvocationAdapter.c line: 425

5. What the user actually sees is Byte Buddy's downstream error, which points at the agent and the JDK,
   not at surefire:

java.lang.IllegalStateException: Could not self-attach to current VM using external process
	at net.bytebuddy.agent.ByteBuddyAgent.installExternal(ByteBuddyAgent.java:710)

So on 3.6.0 any test that attaches an agent at runtime (BlockHound, ByteBuddyAgent.install(),
profilers, Mockito's inline mock maker in setups where it self-attaches) can break, with no hint that
the report layer is involved. It took an -Xlog:exceptions dump to find the Attach Listener thread
in the middle of it.

On the fix

Agreed on catching RuntimeException in tryLoadClass. Two additions worth considering:

• StackWalkerStrategy.<clinit> does not need the TCCL at all — java.lang.StackWalker is a JDK class,
  so StackWalkerStrategy.class.getClassLoader() (or ClassLoader.getPlatformClassLoader()) removes the
  dependency on whatever the current thread happens to carry.
• StackTraceProvider.getStack() and the rest of the ConsoleOutputCapture path could be made
  exception-proof independently: failing to collect diagnostic stack data should degrade to an empty
  stack, never propagate into user code that is only printing a line. As the agent case shows, an
  exception thrown out of a println can break things far outside surefire's own reporting.

Workaround

For the agent-attach case, suppressing the JDK warning is enough, since nothing is then printed from the
Attach Listener thread:

<argLine>-XX:+EnableDynamicAgentLoading</argLine>

Otherwise pinning maven-surefire-plugin to 3.5.6 works.

Environment: maven-surefire-plugin 3.6.0, Temurin 21.0.12+8-LTS, macOS 26.6.2 (aarch64).

[MatthewRyanRead]

Ran into this when loading the Splunk OTEL agent. The above workaround doesn't work there because that agent does print regardless.