Running a Mockito 5 test suite on JDK 21 or newer prints a warning that a Java agent has been loaded dynamically and that this will be disallowed by default in a future release. Where does that come from and how do you resolve it?

## Why an agent is involved at all The inline mock maker intercepts calls by *retransforming loaded classes* — injecting a dispatcher preamble into method bodies. Retransformation is only available through `java.lang.instrument.Instrumentation`, and you can only obtain an `Instrumentation` instance from a Java agent. Mockito does not ask you to launch the JVM with an agent; instead ByteBuddy's `ByteBuddyAgent.install()` uses the attach API to load `byte-buddy-agent.jar` into the JVM that is already running — self-attachment. That is invisible when it works, which is exactly what the JDK now objects to. ## What JDK 21 changed JEP 451, delivered in JDK 21, is titled *Prepare to Disallow the Dynamic Loading of Agents*. Its reasoning is the "integrity by default" line of work: an agent loaded into a live JVM can rewrite arbitrary code and break invariants the runtime and libraries rely on, and it can be attached by any process with sufficient privileges without the application's knowledge. Rather than break tooling immediately, JDK 21 emits a warning on each dynamic attach: ``` WARNING: A Java agent has been loaded dynamically (.../byte-buddy-agent-x.y.z.jar) WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning WARNING: Dynamic loading of agents will be disallowed by default in a future release ``` Starting the JVM with `-XX:+EnableDynamicAgentLoading` opts in explicitly and removes the warning; the eventual plan is for the default to become disallowed, at which point suites relying on self-attachment would fail rather than warn. Treat the warning as a deprecation notice with an unspecified deadline. ## The clean fix: load the agent at startup Mockito's own guidance is to pass the agent on the command line so nothing is attached dynamically. The jar is `net.bytebuddy:byte-buddy-agent`, which Mockito already brings transitively; the trick is getting its resolved path. Gradle: ```kotlin val mockitoAgent = configurations.create("mockitoAgent") dependencies { mockitoAgent("net.bytebuddy:byte-buddy-agent:1.15.11") } tasks.test { jvmArgs("-javaagent:${mockitoAgent.asPath}") } ``` Maven passes the same thing through Surefire's `argLine`, typically combined with `maven-dependency-plugin`'s `properties` goal so the local-repository path of the agent jar is available as a property. Either way the agent is present from process start, no attach happens, and the warning disappears for the right reason rather than being muted. ## Diagnosing related failures Several neighbouring symptoms come from the same area: - **"Could not self-attach to current VM"** — self-attachment blocked outright. Common on locked-down JVMs, some containers, and JDKs where the attach mechanism is restricted; also seen when the JDK (not just a JRE) tooling is unavailable. The startup `-javaagent` approach fixes it properly. - **Warnings appearing only in CI** — CI often runs a different JDK than developer machines; the JDK version, not the build, decides. - **Suites that must run without any agent** — Android and some GraalVM native-image test setups cannot instrument at all. There the answer is `mockito-subclass` (or the `mock-maker-subclass` resource) and accepting that final types are not mockable. ## How to talk about it The answer that lands is layered: *what* the mechanism is (instrumentation requires an agent; Mockito self-attaches), *why* the JDK complains (JEP 451, integrity by default, dynamic attach to be disallowed), *the correct fix* (`-javaagent` at startup, wired through the test task), and *the escape hatch* (`-XX:+EnableDynamicAgentLoading` to silence today, subclass maker where instrumentation is impossible). Saying "it's only a warning, ignore it" is the weak answer — it is a warning that names its own future as an error.