IT小君
2021-09-30T05:02:01 向后二进制兼容性（或向下兼容性）- 使用旧版本库 API 构建的客户端能够在新版本（wiki）上运行的能力。
向上二进制兼容性（或向前兼容性）- 一种使用新版本库 API 构建的客户端在旧版本（wiki）上运行的能力。
Sun关于JDK Incompatibility in J2SE 5.0 since 1.4.2（以及Java SE 6与J2SE 5.0的兼容性）的一般文档描述了JDK的兼容性如下：
JDK 5.0是向上与Java 2 SDK，除了下面列出的不兼容性。5.0二进制兼容。这意味着，除了提到的不兼容性之外，使用 1.4.2 版编译器构建的类文件将在 JDK 5.0 中正确运行。
我想文档作者在这句话中混淆了术语“向上”和“向后”兼容性。他们描述了“向后”兼容性，但将此功能称为“向上”兼容性。
这是打字错误、错误还是有意使用的术语？JDK 是“向上”还是“向后”兼容？
IT小君 扩展答案以包括最新的 Java ...
来自 Oracle 未注明日期的页面的报价：
兼容性是一个复杂的问题。本文档讨论了与 Java 平台版本相关的三种潜在不兼容性：
- 源：源兼容性涉及将 Java 源代码转换为类文件，包括代码是否仍然可以编译。
- 二进制：二进制兼容性在 Java 语言规范中定义为保留无错误链接的能力。
- 行为：行为兼容性包括在运行时执行的代码的语义。
… 和
Java SE 7 和 Java SE 6 之间的不兼容性 Java SE 7与之前版本的 Java 平台高度兼容。几乎所有现有程序都应无需修改即可在 Java SE 7 上运行。但是，在 JRE 和 JDK 中存在一些潜在的潜在源代码和二进制不兼容问题，涉及罕见的情况和“极端情况”，为了完整性，此处记录了这些问题。
语言、JVM 或 Java SE API 中的 Java SE 7 不兼容性
… 和
JDK 7 在 javac、HotSpot 或 Java SE API 中的不兼容性
（那里没有序言——只是一个不兼容的列表。）
IT小君 只向后。Forward compat（“优雅地接受用于其自身更高版本的输入”）将要求 1.5 JVM 能够运行 1.6 编译代码，但它不能。
向后要求“如果它可以处理旧设备生成的输入”，这是正确的，因为 1.6 JVM 可以运行 1.5 编译代码。
JDK/JRE 的每个版本都对应一个 Java 字节码版本。每个编译器生成特定字节码版本的代码。每个 JVM 都理解一个版本和一个特定字节码版本的所有早期版本。
当 JVM 加载一个类时，它会检查字节码版本，如果它大于 JVM 最新理解的版本，您将收到错误消息。（ClassVersionError 之类的）。
IT小君 Java (VM) 向后兼容。由 java 1.4.2 构建的代码将在 1.5 和 6 虚拟机上运行。JDK 编译器不向后兼容。因此，例如，Java 1.5 无法编译代码以在 1.4.2 上运行。
IT小君 JDK 向后兼容，即符合 1.4.2 规范的字节码将在 Java 5 JVM 上运行
IT小君 根据 wiki 的定义，JDK 向下兼容。
IT小君 它应该是向后兼容的。
IT小君 jdk 向上兼容 - 新版本可以在旧版本上运行
请注意，对于向后兼容的东西，必须有一个向前兼容的对应物（有意或无意）。例如：DVD 阅读器是向后兼容 CD 还是 CD 向前兼容 DVD 阅读器？
在这种情况下，这取决于您是查看编译器（或其生成的字节码）还是虚拟机。
编译器不向后兼容，因为使用 Java5 JDK 生成的字节码不会在 Java 1.4 jvm 中运行（除非使用该
-target 1.4标志编译）。但是 JVM 向后兼容，因为它可以运行旧的字节码。所以我猜他们选择从javac的角度考虑兼容性（因为它是JDK特有的部分），意味着生成的字节码可以在jvm的未来版本中运行（与JRE更相关） ，但也捆绑在 JDK 中）。
简而言之，我们可以说：
（这也是一个早就应该吸取的教训：编写编译器的人通常是对的，而我们使用它们的人却错了 xD）
顺便说一句，向后/向前和向下/向上配对而不是将它们混合在一起不是更有意义吗？