1. 问题背景：Java模块系统的封装限制
1.1 问题的起源
在Java 16及更高版本中，许多使用CGLIB进行动态代理的应用程序会遇到类似的异常：
1
2
| java.lang.IllegalAccessException: class X cannot access class Y (in module Z)
because module Z does not export Y to unnamed module
|
这个问题的核心在于Java模块系统（Java Platform Module System, JPMS）引入的强封装机制。
1.2 CGLIB的传统工作方式
CGLIB（Code Generation Library）作为广泛应用的字节码生成库，其核心工作流程包括：
- 动态生成字节码：在内存中生成新的Java类的字节码（
.class文件格式） - 加载生成的类：将字节码加载到JVM中，使其成为可用的Java类
- 使用反射调用：通过反射访问
ClassLoader.defineClass()方法完成类加载
1
2
3
4
5
6
7
| // CGLIB的传统实现思路（简化版）
public class CglibClassLoader extends ClassLoader {
public Class<?> defineClass(String name, byte[] bytes) {
// 通过反射调用受保护的defineClass方法
return super.defineClass(name, bytes, 0, bytes.length);
}
}
|
1.3 模块系统的限制
模块系统的封装规则导致这个问题：
| 组件 | 身份 | 权限 |
|---|
ClassLoader.defineClass() | 位于java.base模块的java.lang包 | 受保护的方法 |
java.lang包 | 属于java.base模块 | 未开放给外部 |
| CGLIB代码 | 位于未命名模块 | 无权访问未开放的包 |
关键点：java.base模块没有开放java.lang包给未命名模块，这意味着通过反射访问该包内的方法是不被允许的。
2. Byte Buddy的解决方案
2.1 核心转变：拥抱标准API
Byte Buddy没有试图寻找"后门"，而是采用了Java 9引入的官方标准API：java.lang.invoke.MethodHandles.Lookup::defineClass。
2.2 MethodHandles.Lookup::defineClass 的优势
1
2
3
4
5
| // Byte Buddy使用的方式
MethodHandles.Lookup lookup = MethodHandles.lookup();
// 或更精确地，为目标类创建Lookup
Lookup lookup = MethodHandles.privateLookupIn(targetClass, MethodHandles.lookup());
Class<?> dynamicClass = lookup.defineClass(bytecode);
|
为什么这种方式能绕过限制？
- 官方授权：是
java.base模块公开提供的API，调用完全合法 - 上下文感知：
Lookup对象携带了调用者的访问权限上下文 - 内部实现透明：JVM内部可能最终还是调用
defineClass，但这属于实现细节
2.3 Byte Buddy的权限获取策略
场景一：为普通类生成代理
1
2
3
4
5
6
7
8
| // 为目标类创建具有包访问权限的Lookup
Class<?> targetClass = com.example.myapp.BusinessService.class;
MethodHandles.Lookup lookup = MethodHandles.privateLookupIn(
targetClass,
MethodHandles.lookup()
);
// 现在可以在com.example.myapp包中定义新类
Class<?> subclass = lookup.defineClass(subclassBytecode);
|
场景二：Java Agent场景
1
2
3
4
5
6
7
8
| // 通过Instrumentation获取特殊权限
public class MyAgent {
public static void premain(String agentArgs, Instrumentation inst) {
// Agent可以请求开放特定包的访问权限
inst.redefineModule(...);
// 或者使用ClassFileTransformer配合Lookup
}
}
|
3. 技术演进对比
| 维度 | CGLIB | Byte Buddy |
|---|
| 类加载方式 | 反射调用ClassLoader.defineClass | MethodHandles.Lookup::defineClass |
| 模块兼容性 | Java 16+ 失败 | Java 9+ 原生支持 |
| 权限模型 | 攻击私有API | 遵循模块系统权限 |
| 维护策略 | 传统方式 | 主动适配模块系统 |
4. 实践建议
4.1 升级到Byte Buddy
如果你的项目还在使用CGLIB并遇到模块系统限制：
1
2
3
4
5
6
| <!-- Maven依赖 -->
<dependency>
<groupId>net.bytebuddy</groupId>
<artifactId>byte-buddy</artifactId>
<version>1.14.11</version>
</dependency>
|
4.2 保持模块兼容性
1
2
3
4
5
6
7
8
9
10
| // Byte Buddy自动处理模块兼容性
DynamicType.Unloaded<?> dynamicType = new ByteBuddy()
.subclass(Object.class)
.method(ElementMatchers.named("toString"))
.intercept(FixedValue.value("Hello World!"))
.make();
// 自动选择合适的类加载策略
Class<?> dynamicClass = dynamicType.load(getClass().getClassLoader())
.getLoaded();
|
5. 总结
Byte Buddy成功的关键在于：
- 主动拥抱变化：维护者深度参与OpenJDK社区讨论
- 遵循标准：采用官方推荐的标准API
- 灵活适配：根据不同场景选择合适的权限获取策略
- 前瞻性设计：早在Java 9就为模块系统做好了准备
核心启示：在Java生态系统中，当遇到模块系统限制时，寻找官方提供的标准API往往是比寻找"后门"更可持续的解决方案。Byte Buddy的成功不仅展示了技术实力，更体现了开源项目与平台协同发展的最佳实践。