How MyBatis Instantiates Mapper Interfaces with JDK Dynamic Proxies

During a casual walk, the author wondered why MyBatis can return an instance of a mapper interface without an explicit implementation class. The answer lies in JDK dynamic proxies and a custom “投鞭断流” (whip‑break) mechanism that intercepts method calls and maps them to SQL statements.

1. Custom JDK Dynamic Proxy for Automatic Mapper Creation

First, define a POJO (image omitted for brevity).

Then create the mapper interface UserMapper.java (image shown).

Implement a custom InvocationHandler (image shown).

In this handler, the target is set to this, turning the real object into a placeholder. When the proxy intercepts a method call, the original target is no longer needed.

A test program (image) demonstrates the output (image), revealing the underlying mechanism of MyBatis automatic mapper generation.

The author notes that the deliberately simple style is meant to make the code feel approachable to beginners.

2. Source Code Analysis of MyBatis Mapper Proxy

A test class (image) is used to illustrate the generated mapper.

The mapper interface looks like (image).

Key parts of MapperProxy.java and MapperProxyFactory.java are shown (images), demonstrating how MyBatis builds the proxy and binds method calls to SQL statements.

3. Can Mapper Interface Methods Be Overloaded?

Example of an overloaded method (image) is presented.

Answer: No. MyBatis uses the fully‑qualified package+Mapper+method name as a key to locate the corresponding SQL in XML. Overloaded methods would create ambiguous keys, so MyBatis forbids method overloading in mapper interfaces.