源码兼容性指旧Java代码无需修改即可用新JDK的javac编译通过，如Java 8代码在OpenJDK 17上编译成功即满足；二进制兼容性指旧class文件可直接在新JDK的java命令中运行不报NoClassDefFoundError等错误；ABI兼容是系统级要求，涉及glibc、动态库等底层匹配；模块系统引入后需显式声明依赖，否则运行时抛ClassNotFoundException。
源码兼容性看的是编译阶段能不能过
源码兼容意味着你现有的 .java 文件，不加修改、不改语法、不换 API 调用方式，就能用新 JDK 的 javac 成功编译。比如 Java 8 代码在 OpenJDK 17 上运行 javac 编译，只要没用到已被移除的 API（如 javax.xml.bind 在 JDK 11+ 中默认不可见），就属于源码兼容。
但要注意：源码兼容 ≠ 运行时不出错。例如你在 Java 8 写了 new Date().toInstant()，这个方法是 Java 8 没有的，编译直接失败；而如果用了 Thread.stop()，它虽已标记为 @Deprecated，但编译仍通过——这是源码兼容，但运行时可能被禁用或抛异常。
- 常见破坏源码兼容的改动：删除 public 类/方法、改变方法签名（参数类型、返回值）、将接口方法改为
default以外的实现方式 - OpenJDK 从 8 到 17，
javac默认语言级别仍保持向后兼容（除非显式用--source 17），所以老代码通常能编译，但会收到警告 - 真正卡住编译的往往是模块系统引入后的
module-info.java强约束，或移除了旧版rt.jar中的类（如sun.misc.BASE64Encoder）
二进制兼容性决定老 class 文件能不能直接跑
二进制兼容指：你用旧 JDK（比如 OpenJDK 11）编译出的 .class 文件，直接丢进新 JDK（比如 OpenJDK 21）的 java 命令里运行，不报 NoClassDefFoundError 或 NoSuchMethodError —— 这才是真正的“无缝升级”。
这种兼容性由 JVM 规范强制保障：只要类文件格式未变（如 Java 11 的 class 文件主版本号是 55，Java 21 是 65，但 JVM 21 明确支持加载主版本 ≤65 的 class），且符号引用所依赖的类、字段、方法在运行时存在且签名一致，就能加载执行。
- 破坏二进制兼容的典型操作：把 public static 方法改成非 static、删掉一个 public 字段、把类从 public 改成 package-private
- OpenJDK 各版本之间对二进制兼容极其保守，HotSpot JVM 几乎从不破坏它；但 Oracle 曾在 JDK 9 移除
sun.misc.Unsafe的部分构造器，导致某些反射黑科技在启动时直接NoSuchMethodError - 注意：
java -version能跑 ≠ 你的 app 能跑；很多崩溃发生在第一次调用某个被删方法时，而不是 JVM 启动阶段
ABI 兼容是底层系统级的硬门槛
当你说“升级 OpenJDK 后 java -version 都报错”，那已经不是 Java 层面的问题了——是 ABI（Application Binary Interface）不匹配。比如 OpenJDK 11.0.24 Linux x64 二进制包链接了 libz.so.1 的新版符号，但在 CentOS 7.9 上只有 libz.so.1.2.7，连 JVM 进程都拉不起来。
这类问题和 Java 代码完全无关，只和发行版打包方式、glibc 版本、动态库 soname 策略有关。OpenJDK 官方构建默认面向较新的 glibc（如 2.28+），而企业环境大量使用 glibc 2.17（CentOS 7）或 2.23（Ubuntu 16.04）。
- 验证方式：运行
ldd $JAVA_HOME/bin/java，看输出里有没有 “not found” - 临时修复：用
patchelf修改DT_RUNPATH，或手动把兼容版libz.so.1放进$JAVA_HOME/lib - 长期规避：优先选用针对旧系统构建的 OpenJDK 发行版（如 Microsoft Build of OpenJDK、Alpine 的 musl 版、或 Azul Zulu 的 CentOS 7 专用包）
最容易被忽略的其实是模块系统迁移成本
从 Java 9 开始，java.base 等模块默认封装，java.xml.bind、java.corba 等被移出 java.se 聚合模块。这意味着：即使你的代码源码能编译、class 文件能加载，一运行就可能抛 ClassNotFoundException。
这不是兼容性“失效”，而是设计上要求你显式声明依赖。比如 Spring Boot 2.0 之前项目若用了 JAXB，升级到 JDK 11+ 就必须加 --add-modules java.xml.bind 或引入第三方实现（如 Eclipse Moxy）。
- 检查手段：启动时加
-Xlog:module=debug，看哪些模块没被解析 - 工具辅助：用
jdeps --list-deps your-app.jar扫描隐式依赖 - 最坑的是：某些库（如老版 Log4j 1.x）在 JDK 9+ 上静默降级为“不加载 JMX 支持”，功能残缺但无报错
