Question

我在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＆＃34;和许多其他无效的陈述。因此，这些类文件很可能是由MS编译器生成的，然后在Sun JVM上运行。

无论如何，我的问题是;是否有人知道Java早期版本中的兼容性承诺？这是一个大问题，还是故意牺牲？或者稍后有一个决定，比如说Java 1.4或Java 5只是简单地删除了JDK 1.0支持？

Answer 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（主要与以前的版本二进制兼容，有些注释表明前向兼容性可能会起作用，但未经过测试）

Java二进制兼容性发生了什么变化？

1 个答案: