自行编译OpenJDK9运行DaCapo batik基准测试遇类缺失异常的解决方法

咱们先把问题拆明白：你遇到的NoClassDefFoundError和ClassNotFoundException，核心原因是OpenJDK 9彻底移除了com.sun.image.codec.jpeg这个Sun专属的私有API包，而DaCapo 9.12-MR1版本的batik测试刚好依赖了这个包里的TruncatedFileException类。

Oracle JDK 8里还保留这些非标准的内部API，但从JDK 9开始，Java引入了模块化系统（Project Jigsaw），把大量不对外公开的内部实现给砍掉了——就是为了避免开发者依赖这些随时可能变更的私有代码，保证JDK的稳定性和兼容性。

根据你的需求，给你三个不同优先级的方案：

1. 直接用JDK 8跑测试（最省心） #

既然你已经验证Oracle JDK 8能正常跑通，这绝对是最快的解决方案。如果测试没有硬性要求用JDK 9，直接切换回去就行：

java -jar dacapo-9.12-MR1-bach.jar batik

2. 修改DaCapo代码适配JDK 9+（长期靠谱） #

如果必须用JDK 9及以上版本，就得动手修改batik测试里依赖私有API的代码，换成Java标准库的API：

• 找到org.apache.batik.ext.awt.image.codec.jpeg.JPEGRegistryEntry类里第87行左右引用TruncatedFileException的地方
• 把对这个私有异常的捕获，换成标准的javax.imageio.IIOException——ImageIO处理JPEG文件时，类似截断的错误会抛出这个标准异常
• 重新编译DaCapo的测试包，再用你的OpenJDK 9运行

3. 临时开放JDK 9的私有API访问（仅应急测试） #

JDK 9还留了个临时口子，可以通过启动参数强制开放私有API，但这个方法在JDK 10及以后就彻底用不了了，而且不符合Java官方规范，只适合临时验证：

/home/wxf/9dev/build/linux-x86_64-normal-server-slowdebug/jdk/bin/java \
--add-exports java.desktop/sun.awt.image.codec=ALL-UNNAMED \
-jar dacapo-9.12-MR1-bach.jar batik

记住，这只是权宜之计，长期来看还是得用方案2做代码适配。

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