Java二进制兼容性发生了什么变化？
我偶然发现了一套旧的课程，日期是1997年3月。那是在我尝试学习Java的时候，它是JDK 1.0.2
有趣的是，从那时起，我的源文件和类文件都完好无损。源代码仍然可以按预期编译和执行，这真的很酷。但是Java不是也应该保持二进制兼容性吗？好吧，在这个过程中的某个地方，格式不再有效。Java 8虚拟机将报告；
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编译器很乐意接受"public synchronized class Abc“和许多其他无效语句。因此，这些类文件很可能是由MS编译器生成的，然后在Sun JVM上运行。
无论如何，我的问题是:周围有谁知道Java早期版本中的兼容性承诺？这是一件大事，还是故意牺牲的？还是很晚才决定放弃对JDK 1.0的支持，比如Java1.4或Java5？
回答 1
Stack Overflow用户
发布于 2016-04-21 01:37:51
正如您所提到的，这个问题可能是在编译器从Microsoft编译器切换到Sun编译器时引入的。Sun声明，由Microsoft编译器生成的类文件不遵循Java规范，因此是无效的。
您可以在here找到更多详细信息
此错误是由旧版JDK1.0.2或1.1编译器生成的字节码引起的。在过去，许多这样的编译器生成的字节码不符合Java VM规范。由于最近的J2SE版本中的验证器对错误的类格式有更严格的要求，因此在加载这些错误的类文件时，VM会抛出ClassFormatError。
对于一般的问题，Java仍然坚定地致力于向后兼容，并且从来没有重大突破。在边缘问题上，从一个版本到另一个版本通常会有一些小的中断。我知道没有主表，但下面是各个版本的表：
- Java 8 (与Java 7)
- Java 7完全二进制兼容(主要与Java二进制兼容(主要与Java5二进制兼容，加上一些混淆程序在规范之外生成的类文件，因此这些类文件可能不会run)
- Java 5 (主要是与Java1.4.2二进制兼容，以及关于obfuscators)
- Java 1.0 - 1.4.2的相同评论(主要是与以前版本的二进制兼容，一些评论认为向前兼容性甚至可以工作，但未经过测试)
https://stackoverflow.com/questions/36660420
复制相似问题