1. 简介
但凡尝试升级到 Java 9 的开发者，十有八九都会遇到一个坑：原本在旧版本运行正常的代码，编译时突然抛出 NoClassDefFoundError。
本文将聚焦一个常见的缺失类 JAXBException，探讨几种解决方案。这些方法不仅适用于 JAXB，也适用于升级 Java 9 时可能缺失的其他类。
2. 为什么 Java 9 找不到 JAXBException？
Java 9 最受关注的特性之一是模块系统。核心目标是将 JVM 核心类及相关项目拆分成独立模块，从而通过仅包含运行所需的最小类集，构建出更轻量的应用。
但代价是：许多类默认不再出现在 classpath 中。JAXBException 就属于新 Jakarta EE 模块中的 java.xml.bind，由于它并非 Java 运行时的必需模块，默认不可用。
当应用尝试使用 JAXBException 时，会直接报错：
NoClassDefFoundError: jakarta/xml/bind/JAXBException
要解决这个问题，必须显式引入 java.xml.bind 模块。下面提供几种实现方式。
3. 短期解决方案
最粗暴的方式是添加 –add-modules 命令行参数：
--add-modules java.xml.bind
但这种方式存在两个明显缺陷：
❌ 版本兼容性问题–add-modules 是 Java 9 新增参数。如果应用需要跨多个 Java 版本运行，就得维护多套构建文件（每个版本一套）。
⚠️ 潜在风险
虽然可用 -XX:+IgnoreUnrecognizedVMOptions 让旧版 JVM 忽略该参数，但会带来副作用：任何拼写错误的参数都不会被检测到。比如错误设置堆内存参数时，应用仍会启动，但实际运行配置与预期不符。
❌ 未来兼容性差–add-modules 在后续 Java 版本中已被标记为废弃，升级后可能再次面临同样问题。
4. 长期解决方案
更优雅的方案是利用依赖管理工具（如 Maven），将 JAXB API 作为普通依赖引入：
<dependency>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>4.0.1</version>
</dependency>
✅ 跨版本兼容
这种方式在任何 Java 版本下都能工作，且不受未来版本变更影响。
⚠️ 注意事项
- 上述依赖仅包含 Jakarta XML Binding API（含 JAXBException），根据实际需求可能需要补充其他模块
- Maven 坐标名可能与 Java 9 模块名不同（如本例中的
jakarta.xml.bind-api），可在 Maven 中央仓库 查找最新版本
5. 总结
Java 9 模块系统确实带来了应用体积减小、性能提升等优势，但也引入了兼容性问题。升级时需要明确应用实际依赖的模块，并确保它们在 classpath 中可用。
关键点回顾：
- 短期方案用
–add-modules快速解决，但存在兼容性隐患 - 长期方案通过依赖管理工具显式引入模块，是更可靠的实践
- 处理缺失类时需区分模块名和 Maven 坐标名差异