ByteBuddy使用Calendar类加载器加载动态子类报ClassNotFoundException咨询

核心矛盾来自JDK类加载器的层级规则，和ByteBuddy WRAPPER加载策略的委派逻辑：

• 所有java.*包下的JDK核心类（包括java.util.Calendar、java.lang.Object）都由**启动类加载器（Bootstrap ClassLoader）**加载。这个加载器是JVM底层用C++实现的，没有对应的Java层面ClassLoader实例，因此Java代码中调用核心类的getClassLoader()方法，返回值永远是null。
• 你自定义的MyMethodInterceptor属于业务classpath下的自定义类，只能被**应用类加载器（即ClassLoader.getSystemClassLoader()返回的系统类加载器）**识别加载，启动类加载器的搜索范围仅限JDK核心类库目录，完全看不到业务classpath下的类。

WRAPPER策略的加载逻辑 #

ClassLoadingStrategy.Default.WRAPPER的默认行为是创建一个独立的ByteArrayClassLoader实例，将你传入的类加载器参数设为新类加载器的父加载器，严格遵循双亲委派模型加载类：

1. 当传入Calendar.class.getClassLoader()作为参数时，实际传入值为null，新生成的ByteArrayClassLoader的父加载器会被指定为启动类加载器。
2. 动态生成的Calendar子类在链接阶段需要引用MyMethodInterceptor类，按照双亲委派规则会先委托父加载器（启动类加载器）查找，启动类加载器无法找到业务侧的拦截器类；而ByteArrayClassLoader本身仅持有生成的动态子类字节码，同样找不到该类，最终抛出ClassNotFoundException。你看到异常信息中类名位置为空，是ByteBuddy类加载逻辑的异常栈打印特性导致的，实际缺失的就是自定义拦截器类。

替换为系统类加载器后正常运行的原因 #

当传入ClassLoader.getSystemClassLoader()作为父加载器时，新建的ByteArrayClassLoader会顺着类加载委派链查找所有依赖类：

• 查找JDK核心类（如Calendar）时，会向上委派给平台类加载器、最终到启动类加载器，可以正常找到
• 查找业务类（如MyMethodInterceptor）时，父加载器（应用类加载器）本身就负责加载classpath下的所有业务类、第三方依赖类，可以正常找到，因此不会抛出类找不到异常。

如果要给JDK核心类生成动态代理，更稳妥的类加载器选择是传入自定义拦截器本身的类加载器，即MyMethodInterceptor.class.getClassLoader()，在普通Java SE/Jakarta EE应用中，这个类加载器和系统类加载器是同一个实例，不会出现加载失败问题。

内容的提问来源于stack exchange，提问作者zxzxzx