与JSE JavaDoc的类层次差异及ASM StackMapTable跨VM兼容问题

这个问题正好踩中了Java API设计里一个容易被忽略的坑：JavaDoc公开的类层次结构，和不同VM（甚至同一VM的不同版本）的实际实现类层次可能存在不小的差异。我来分两部分解答你的问题：

一、JavaDoc与实际VM类层次的核心差异 #

• 隐藏的内部实现类：JavaDoc只会展示对外公开的API类/接口，而JDK的很多核心API（比如日期时间、集合框架）都会用包私有或者内部实现类来封装具体逻辑。比如你遇到的ChronoLocalDateImpl就是Java时间API的内部实现类，它根本不会出现在公开的JavaDoc里。不同VM厂商（比如OpenJDK vs Oracle JDK）或者同一厂商的不同版本，完全可能用不同的内部类来实现同一个公开接口。
• 版本迭代中的实现变更：即使是同一个VM，随着Java版本升级，内部的类继承关系也可能调整。比如Java 8刚推出java.time包时的实现，和Java 11/17里的实现就有不少内部结构的变化，但公开的API（比如ChronoLocalDate、ThaiBuddhistDate）会保持兼容，不会影响上层代码。
• 厂商特有的优化实现：像IBM J9、Azul Zing这类第三方VM，可能会针对特定场景优化内部实现，使用和OpenJDK不同的继承链来实现公开API，这也会导致类层次的差异。

二、解决ASM生成StackMapTable的崩溃问题 #

你现在遇到的崩溃，本质是因为把内部实现类ChronoLocalDateImpl写入了StackMapTable，而这个类在其他VM（甚至不同版本的同一款VM）中要么不存在，要么无法访问。解决思路很明确：

• 始终使用公开的API类型：对于ThaiBuddhistDate和HijrahDate，它们都实现了公开的ChronoLocalDate接口，所以你应该把StackMapTable里的类型设置为java.time.chrono.ChronoLocalDate，而不是内部的ChronoLocalDateImpl。
• 调整类型推导逻辑：在自动确定栈上类型时，不要直接取运行时的最具体类，而是向上追溯，找到第一个公开（public）的超类或实现的公开接口。比如可以通过检查类的修饰符，过滤掉非public的类，直到找到符合要求的公开类型。
• 验证生成结果：生成字节码后，用javap -v命令查看字节码文件的StackMapTable部分，确保里面的类型都是JavaDoc里能查到的公开API类/接口。

这样生成的StackMapTable就能在所有兼容的VM上正常工作，不会因为内部实现类的差异导致崩溃。

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