JDK CGLIB

In the realm of modern Java development, the ability to extend the functionality of an object without modifying its original source code is a powerful architectural requirement. This is the essence of the Proxy Pattern. While static proxies require developers to manually write a wrapper class for every target object—a process that is both tedious and unscalable—Dynamic Proxy technology automates this by generating proxy classes at runtime.

Dynamic proxies serve as the foundational mechanism for industry-standard frameworks such as Spring AOP (Aspect-Oriented Programming) and MyBatis. They enable cross-cutting concerns like transaction management, logging, security authentication, and lazy loading to be applied seamlessly across an application. In the Java ecosystem, two primary technologies dominate this space: JDK Dynamic Proxy and CGLIB.

JDK Dynamic Proxy

The JDK Dynamic Proxy is a native implementation provided by the Java standard library, located within the java.lang.reflect package. Its implementation relies heavily on the Proxy class and the InvocationHandler interface.

Core Principle

The fundamental constraint of JDK Dynamic Proxy is that the target class must implement at least one interface. At runtime, the JDK generates a new class (typically named something like $Proxy0) that implements all the interfaces of the target object. When a method is called on this proxy, the call is intercepted and routed to the InvocationHandler.invoke() method, where the developer can inject custom logic before or after the actual method execution.

Implementation Example

To use JDK Dynamic Proxy, we first define an interface and its implementation:

public interface UserService {
    void save(String name);
}

public class UserServiceImpl implements UserService {
    @Override
    public void save(String name) {
        System.out.println("Saving user: " + name);
    }
}

Next, we create the proxy instance using Proxy.newProxyInstance:

UserService target = new UserServiceImpl();

UserService proxy = (UserService) Proxy.newProxyInstance(
        target.getClass().getClassLoader(),
        target.getClass().getInterfaces(),
        (p, method, methodArgs) -> {
            System.out.println("Before method execution: " + method.getName());
            Object result = method.invoke(target, methodArgs);
            System.out.println("After method execution");
            return result;
        });

proxy.save("Alice");

In this example, the proxy intercepts the save method, allowing us to wrap the original logic with "before" and "after" behaviors.

CGLIB Dynamic Proxy

CGLIB (Code Generation Library) is a high-performance bytecode manipulation library based on the ASM framework. Unlike the JDK approach, CGLIB does not rely on interfaces.

Core Principle

CGLIB operates through inheritance. It dynamically generates a subclass of the target class at runtime. Because the proxy is a subclass, it can intercept method calls by overriding them. This makes CGLIB the go-to solution when the target class does not implement any interfaces.

However, this inheritance-based strategy introduces specific limitations:

• It cannot proxy final classes, as they cannot be subclassed.
• It cannot proxy final methods, as they cannot be overridden.
• It cannot intercept private methods, as they are not visible to the subclass.

Implementation Example

First, ensure the CGLIB dependency is included in your project (e.g., via Maven):

<dependency>
    <groupId>cglib</groupId>
    <artifactId>cglib</artifactId>
    <version>3.3.0</version>
</dependency>

Here is how you implement a CGLIB proxy for a class without an interface:

public class OrderService {
    public void createOrder(String orderId) {
        System.out.println("Creating order: " + orderId);
    }
}

// ... inside your main logic
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(OrderService.class);
enhancer.setCallback((MethodInterceptor) (obj, method, methodArgs, proxy) -> {
    System.out.println("Before method: " + method.getName());
    // Use proxy.invokeSuper to call the original method logic
    Object result = proxy.invokeSuper(obj, methodArgs);
    System.out.println("After method");
    return result;
});

OrderService proxy = (OrderService) enhancer.create();
proxy.createOrder("ORD-12345");

Crucial Note: When using CGLIB, you must use proxy.invokeSuper(obj, methodArgs) to call the original method. Using method.invoke(target, ...) can lead to infinite recursion or unexpected behavior.

Comparative Analysis

The following table summarizes the key differences between the two technologies:

Note: In modern JVMs (Java 8 and later), the performance gap between reflection-based JDK proxies and CGLIB has narrowed significantly, making the choice more about architectural compatibility than raw speed.

Proxy Strategies in Spring AOP

Spring AOP is highly intelligent in how it selects a proxying strategy. By default, it follows these rules:

1. Interface-based: If the target object implements an interface, Spring defaults to JDK Dynamic Proxy.
2. Class-based: If no interface is present, Spring falls back to CGLIB.
3. Explicit Configuration: You can force Spring to use CGLIB for all proxies by setting spring.aop.proxy-target-class=true in your properties, or by using the @EnableAspectJAutoProxy(proxyTargetClass = true) annotation.

Since Spring Boot 2.x, the default behavior has shifted toward favoring CGLIB to avoid common ClassCastException issues when developers attempt to inject a class type instead of its interface.

Professional Best Practices and Pitfalls

To avoid common production issues when working with dynamic proxies, keep these points in mind:

• Avoid the "Self-Invocation" Trap: This is the most common AOP failure. If a method A() calls method B() within the same class using this.B(), the call to B() will not be intercepted by the proxy. The proxy only intercepts calls coming from outside the object.
• Design for Interfaces: Whenever possible, follow the "Program to an Interface" principle. This makes your code more modular and allows the lightweight JDK proxy to work seamlessly.
• Mind the final Keyword: If you anticipate using CGLIB (especially in Spring environments), ensure your service classes and public methods are not marked as final.
• Monitor Metaspace: Since both technologies generate new classes at runtime, excessive dynamic proxy generation can lead to increased consumption of Metaspace memory. In highly dynamic environments, monitor your memory usage to prevent OutOfMemoryError.

Summary

Choosing between JDK Dynamic Proxy and CGLIB is not about finding a "better" tool, but about selecting the right tool for your architectural constraints. JDK Dynamic Proxy is the lightweight, native choice for interface-driven designs, while CGLIB provides the flexibility to enhance concrete classes through inheritance. Understanding these nuances is essential for mastering Spring AOP and building robust, scalable Java applications.