如何让Hessian 4.0.66兼容Java 8、11与17版本？

问题背景 #

原使用Hessian 3.2.0在Java 8/11运行正常，但迁移到Java 17时触发InaccessibleObjectException（因模块系统限制无法访问StackTraceElement的私有字段），临时解决方案是添加JVM参数--add-opens java.base/java.lang=ALL-UNNAMED。升级到Hessian 4.0.66后常规场景正常，但序列化包含重复对象实例的数据时，抛出IndexOutOfBoundsException（推测是序列化端用IdentityIntMap管理对象引用，反序列化端无法匹配索引），且运行/调试模式行为存在差异。

可行解决方案 #

1. 替换Unsafe反序列化器为反射式实现 #

Hessian 4.0.66的UnsafeDeserializer在处理重复对象引用时存在bug，且依赖Unsafe类在Java 17下有模块访问限制。可以强制使用基于反射的JavaDeserializer来绕过这两个问题：

// 自定义SerializerFactory，优先使用JavaDeserializer
SerializerFactory serializerFactory = new SerializerFactory();
serializerFactory.addFactory(new JavaDeserializerFactory());

// 序列化时使用自定义工厂
Hessian2Output output = new Hessian2OutputStream(outputStream);
output.setSerializerFactory(serializerFactory);
output.writeObject(data);

// 反序列化时同样使用该工厂
Hessian2Input input = new Hessian2InputStream(inputStream);
input.setSerializerFactory(serializerFactory);
Object result = input.readObject();

优点：无需额外JVM参数，同时解决Java 17模块访问限制和重复对象序列化bug；缺点：反射实现性能略低于Unsafe，但多数场景可接受。

2. 精细化配置JVM模块访问参数 #

若必须保留Unsafe实现的性能，可替换全局ALL-UNNAMED的opens参数为仅开放给Hessian模块，降低安全风险：

--add-opens java.base/java.lang=com.caucho.hessian
--add-opens java.base/java.util=com.caucho.hessian

优点：保持Unsafe的高性能；缺点：仍需依赖JVM启动参数，且需要针对Hessian实际访问的模块做精准配置。

3. 应用官方修复或自定义补丁 #

检查Hessian官方仓库是否存在针对该重复对象引用bug的修复：

• 搜索相关issue（如"IndexOutOfBoundsException duplicate objects"或"IdentityIntMap deserialization"），若已有修复PR，可使用快照版本或自行编译补丁。
• 若自行修复，需调整Hessian2Input中处理对象引用的逻辑，确保反序列化时IdentityIntMap的索引与序列化端一致。

优点：从根源解决问题，保留原有性能；缺点：需要额外的编译或版本管理成本。

4. 临时禁用对象引用优化 #

若业务允许不保留重复对象的引用关系，可关闭Hessian的对象引用序列化功能，避免索引匹配问题：

// 序列化端禁用引用
Hessian2Output output = new Hessian2OutputStream(outputStream);
output.setRef(false); // 不复用对象引用，重复对象将被多次序列化
output.writeObject(data);

// 反序列化端无需额外配置

优点：快速生效，无需修改核心逻辑；缺点：会增加序列化数据体积，且无法保留对象引用关系，仅适合临时应急。

兼容性验证 #

调整完成后，需在Java 8、11、17环境下分别测试：

• 常规序列化/反序列化场景
• 包含重复对象实例的复杂数据场景
• 异常栈信息的序列化（验证Java 17下模块访问是否正常）

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