Что случилось с Java Binary Compatibility?

Я встретил старый набор классов от марта 1997 года. Это было в то время, когда я пытался изучить 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)

Класс-нарушитель является суперклассом класса, который я вызываю из командной строки.

Еще одна деталь, в те времена, Microsoft все еще находилась в лагере Java, и я помню, что их javac был более совместим с плохо написанным синтаксисом. Компилятор Sun с радостью примет "общедоступный синхронизированный класс Abc" и многие другие недопустимые операторы. Таким образом, существует большая вероятность того, что эти файлы классов были сгенерированы компилятором MS и затем запущены на Sun JVM.

Во всяком случае, мой вопрос: Есть ли кто-нибудь, кто знает о приверженности совместимости в ранних версиях Java? Было ли это грандиозным событием, или его жертвовали нарочно? Или было решение гораздо позже, скажем, Java 1.4 или Java 5, чтобы просто отказаться от поддержки JDK 1.0?

Ответ 1

Как вы упомянули, проблема, скорее всего, возникла, когда компилятор переключился с компилятора Microsoft на компилятор Sun. Sun заявила, что файлы классов, сгенерированные компилятором Microsoft, не соответствуют спецификации Java и, следовательно, недействительны.

Подробнее здесь:

Эта ошибка вызвана байт-кодом, сгенерированным из старого JDK 1.0.2 или 1.1 компиляторы. В прошлом многие из этих компиляторов генерировали байт-код что не соответствует спецификации Java VM. Поскольку верификаторы в последних выпусках J2SE гораздо более строги относительно плохого класса формат, 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 (в основном бинарный, совместимый с предыдущими версиями, некоторые комментарии о том, что передовая совместимость может даже работать, но не протестирована)