skip to content

What is the inline mock-maker, why is it required to mock statics, and how do its versions/configuration differ across Mockito releases?

level: middleimportance: should knowfreq 40%

answer

  1. MockMaker = the engine that builds mocks
  2. subclass maker can't do statics/finals
  3. inline maker = ByteBuddy + JVM instrumentation, in-place redefine
  4. opt-in pre-5 (mockito-inline or MockMaker resource file)
  5. default in Mockito 5+

basics

~20 s

The inline mock-maker is Mockito's engine that rewrites bytecode at runtime so it can intercept static (and final) methods. mockStatic only works with it. It's the default in Mockito 5+; in older versions you added the mockito-inline dependency.

solid answer

~40 s

Mockito normally mocks by generating subclasses/proxies, which can't touch static or final methods. The inline mock-maker is an alternative MockMaker that uses the JVM instrumentation API and ByteBuddy to redefine classes in place, enabling mocking of statics, finals, and constructors. mockStatic, mockConstruction, and mocking final classes all require it. In Mockito 2/3/4 it was opt-in: add the mockito-inline artifact, or register it via a META-INF/services-style file (mockito-extensions/org.mockito.plugins.MockMaker) containing mock-maker-inline. Since Mockito 5 the inline maker is the default, so mockito-core alone supports mockStatic and the separate mockito-inline artifact is deprecated. Practically: on Mockito 5 you just use mockStatic; on older versions a missing inline maker throws an error telling you the current mock-maker doesn't support static mocking.

go deeper

for a junior

Knows you may need an extra dependency or that it 'just works' on newer Mockito, without the mechanism.

for a middle

Explains that the inline maker is required for mockStatic, how to enable it pre-5, and that it's the default in 5+.

for a senior

Describes the subclass-vs-inline mechanism (ByteBuddy/instrumentation, in-place redefine), the failure message, and the agent/perf trade-off.

for a principal

Owns the Mockito version/upgrade policy, weighs the inline-maker cost and JDK sensitivity, and limits where statics/finals get mocked at all.

## What a 'mock-maker' is Mockito is pluggable: a **MockMaker** is the component that actually *builds* a mock. There are two main strategies: 1. **Subclass mock-maker (default historically).** Mockito generates a runtime **subclass/proxy** of the type and overrides its methods to intercept calls. This is the classic, fast approach — but it has hard limits: you cannot override a `final` method/class (can't subclass/override it) and you cannot subclass a **static** method at all (statics aren't inherited/overridable). So this maker physically *cannot* mock statics, finals, or constructors. 2. **Inline mock-maker.** Instead of subclassing, it uses the **JVM Instrumentation API** (a Java agent) together with **ByteBuddy** to **redefine the existing class's bytecode in place**. Because it rewrites the actual class, it can install interception for `static` methods, `final` methods/classes, and constructor calls. This in-place redefinition is exactly what `Mockito.mockStatic`, `Mockito.mockConstruction`, and mocking final types rely on. ## Why statics specifically need it A static method is dispatched against the class, with no instance and no override mechanism. The only way to intercept it is to change the class's own bytecode (or its call sites). That is the inline maker's whole purpose, which is why `mockStatic` throws if the inline maker isn't active. ## Version timeline & configuration - **Mockito 2/3/4:** the inline maker is **opt-in**. Two ways to enable it: - Depend on the **`mockito-inline`** artifact (a thin wrapper that ships the registration), *instead of / alongside* `mockito-core`; or - Add a resource file `src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker` whose single line is `mock-maker-inline`. - **Mockito 5+ (2023 onward):** the inline maker is the **default** mock-maker bundled in `mockito-core`. You don't add anything; `mockStatic` just works. The standalone `mockito-inline` artifact is **deprecated/empty** because its behavior is now built in. ## What failure looks like On an older setup without the inline maker, `mockStatic(...)` throws something like *'The used MockMaker SubclassByteBuddyMockMaker does not support the creation of static mocks'* with a hint to switch mock-makers. The fix is to enable the inline maker as above (or upgrade to Mockito 5). ## Trade-offs The inline maker uses a Java agent and in-place class redefinition, which is slightly heavier and historically had edge cases (e.g. self-attaching agents, JDK version sensitivity). That cost — plus the fact it lets you mock things you arguably shouldn't (statics, finals) — is part of why heavy reliance on it is treated as a smell rather than a default tool.

  • On Mockito 5, do you still add the mockito-inline dependency to use mockStatic?
    No. The inline maker is the default in mockito-core on Mockito 5, so mockStatic works out of the box; the separate mockito-inline artifact is deprecated.
  • Besides static methods, what else does the inline mock-maker unlock?
    Mocking final classes/methods and intercepting constructor calls (Mockito.mockConstruction). The subclass maker can't do any of those.

saying these in an interview costs you the question

  • Thinking mockStatic works with the default subclass mock-maker on Mockito 4.
  • Confusing mockito-inline (the artifact) with the inline maker still being needed on Mockito 5 (it's built in there).
  • Believing the inline maker has no cost — it uses a Java agent and in-place redefinition.

context

resolving links…