Java 二进制兼容性发生了什么？答案

【问题标题】：What happened to Java Binary Compatibility?Java 二进制兼容性发生了什么？
【发布时间】：2016-08-08 05:02:30
【问题描述】：

我遇到了一组 1997 年 3 月的旧课程。那是我尝试学习 Java 的时候，它是 JDK 1.0.2

有趣的是，从那时起，我的源文件和类文件都完好无损。源代码仍然按预期编译和执行，这真的很酷。但是Java不应该也保留二进制兼容性吗？好吧，一路走来，格式不再有效。 Java 8 VM 将报告；

Exception in thread "main" java.lang.ClassFormatError: Invalid start_pc 65535 in LocalVariableTable in class file bali/core/Application
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:455)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
    :
    [snip many ClassLoader calls]
    :
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)

违规类是我从命令行调用的类的超类。

更详细一点，那时候微软还处于 Java 阵营，我记得他们的 javac 更符合糟糕的语法。 Sun 编译器很乐意接受“公共同步类 Abc”和许多其他无效语句。因此，这些类文件很有可能是由 MS 编译器生成，然后在 Sun JVM 上运行的。

无论如何，我的问题是；周围有没有人了解 Java 早期版本的兼容性承诺？是大不了，还是故意牺牲？还是很久以后才做出决定，比如 Java 1.4 或 Java 5 干脆放弃对 JDK 1.0 的支持？？

【问题讨论】：

我在网上发现了一些 cmets，它们表明旧的 javac 已损坏，生成了错误的字节码，而更高版本的验证程序发现了其中一些错误。 Java 6 中似乎发生了一个特殊的变化，这可能已经开始被发现了。
嗯，类文件无效。 Java 二进制兼容性仅适用于有效的类文件。仅仅因为一些早期的 JVM 是宽松的，并不能改变这一点。
如果修复破坏了您之前做出的兼容性承诺，是否修复某个错误总是一个很大的难题。但在这种情况下，所讨论的错误可能非常严重，以至于认为破坏错误兼容性是值得的。
你能用javap反汇编类吗？

标签： java history

【解决方案1】：

正如您提到的，当编译器从 Microsoft 编译器切换到 Sun 编译器时，可能会引入该问题。 Sun 表示，Microsoft 编译器生成的类文件不符合 Java 规范，因此无效。

您可以找到更多详情here：

此错误是由旧 JDK 1.0.2 或 1.1 生成的字节码引起的编译器。过去，很多这些编译器生成字节码不符合 Java VM 规范。由于最近的 J2SE 版本中的验证器对坏类更加严格格式，当这些坏类时，VM 会抛出 ClassFormatError 文件已加载。

关于一般问题，Java 仍然坚定地致力于向后兼容，并且从未有过重大突破。在边缘问题上，从发布到发布通常会有轻微的中断。我知道没有主表，但这里有个别版本的表：

Java 8（与 Java 7 完全二进制兼容）
Java 7（大部分二进制兼容 Java 6）
Java 6（主要是与 Java 5 兼容的二进制文件，以及一些混淆器在规范之外生成类文件的注释，因此这些类文件可能无法运行）
Java 5（大部分二进制兼容 Java 1.4.2，加上关于混淆器的相同评论）
Java 1.0 - 1.4.2（主要是二进制兼容以前的版本，一些前向兼容的 cmets 甚至可以工作但未经测试）

【讨论】：

感谢您的出色回答。