Совместим ли JDK "вверх" или "назад"?
Обратная двоичная совместимость (или обратная совместимость) - способность клиентов, основанных на старой версии API библиотеки, работать на новой ( вики).
Бинарная совместимостьвверх (или прямая совместимость) - способность клиентов, созданных с новой версией API библиотеки, работать на старой ( вики).
В общем документе Sun о несовместимости JDK в J2SE 5.0 начиная с 1.4.2 (и совместимости Java SE 6 с J2SE 5.0) описывается совместимость JDK следующим образом:
JDK 5.0 совместим с бинарной версией Java 2 SDK v1.4.2 и выше, за исключением несовместимостей, перечисленных ниже. Это означает, что, за исключением отмеченных несовместимостей, файлы классов, созданные с помощью компиляторов версии 1.4.2, будут работать правильно в JDK 5.0.
Я предполагаю, что авторы документации смешали термины "восходящая" и "обратная" совместимость в этом предложении. Они описывают "обратную" совместимость, но называют эту функцию "восходящей" совместимостью.
Это опечатка, ошибка или предполагаемый термин здесь? Совместим ли JDK "вверх" или "назад"?
8 ответов
Обратите внимание, что для чего-то, чтобы быть обратно совместимым, должен быть аналог, который является совместимым в прямом направлении (преднамеренно или непреднамеренно). Например: совместимы ли устройства чтения DVD с дисками назад или они совместимы с устройствами чтения DVD?
В этом случае это зависит от того, смотрите ли вы на компилятор (или генерируемый им байт-код) или на виртуальную машину.
Компилятор не имеет обратной совместимости, потому что байт-код, созданный с помощью Java5 JDK, не будет работать в Java 1.4 jvm (если не скомпилирован с -target 1.4 флаг). Но JVM обратно совместима, так как может запускать старые байт-коды.
Поэтому я думаю, что они решили рассмотреть совместимость с точки зрения javac (так как это часть, специфичная для JDK), то есть сгенерированный байт-код может быть запущен в будущих выпусках jvm (что больше относится к JRE, но также в комплекте в JDK).
Вкратце можно сказать:
- JDK (как правило) совместимы с форвардом.
- JRE (обычно) обратно совместимы.
(И это также служит уроком, который следует усвоить давно: люди, пишущие компиляторы, обычно правы, а мы, люди, использующие их, ошибаются xD)
Кстати, разве не имеет смысла объединять пары назад / вперед и вниз / вверх, а не смешивать их?
Расширяя ответы, чтобы включить самые последние Java...
Совместимость с Java SE 7 и JDK 7
Цитаты из недатированной страницы Oracle:
Совместимость является сложной проблемой. Этот документ обсуждает три типа потенциальных несовместимостей, связанных с выпуском платформы Java:
- Источник: Совместимость с исходным кодом касается перевода исходного кода Java в файлы классов, включая вопрос о том, компилируется ли этот код или нет.
- Двоичная: двоичная совместимость определяется в Спецификации языка Java как сохраняющая возможность связывания без ошибок.
- Поведенческий: Поведенческая совместимость включает в себя семантику кода, который выполняется во время выполнения.
… а также
Несовместимость между Java SE 7 и Java SE 6 Java SE 7 полностью совместима с предыдущими версиями платформы Java. Почти все существующие программы должны работать на Java SE 7 без изменений. Однако в JRE и JDK есть некоторые незначительные потенциальные источники и двоичные несовместимости, которые связаны с редкими обстоятельствами и "угловыми случаями", которые приведены здесь для полноты.
Несовместимости Java SE 7 в языке, JVM или API Java SE
… а также
Несовместимость между JDK 7 и JDK 6
JDK 7 Несовместимости в javac, в HotSpot или Java SE API
(Там нет преамбулы - просто список несовместимостей.)
Только назад Прямой компат ("изящно принимающий ввод, предназначенный для более поздних версий") потребовал бы, чтобы 1.5 JVM могла запускать скомпилированный код 1.6, чего не может быть.
Обратно требуется "если он может работать с входными данными, сгенерированными старым устройством", что верно, поскольку 1.6 JVM может запускать скомпилированный код 1.5.
Каждый выпуск JDK/JRE совпадает с версией байт-кода Java. Каждый компилятор создает код определенной версии байт-кода. Каждая JVM понимает версию и все более ранние версии конкретной версии байт-кода.
Когда JVM загружает класс, он проверяет версию байт-кода, и если это>, чем последняя понятная версия JVM, вы получите ошибку. (ClassVersionError или что-то).
Java (VM) обратно совместима. Код, созданный в Java 1.4.2, будет работать на 1,5 и 6 виртуальных машинах. Компилятор JDK не имеет обратной совместимости. Так что код не может быть скомпилирован Java 1.5 для запуска на 1.4.2, например.
JDK обратно совместим, т.е. байт-код, соответствующий спецификации 1.4.2, будет работать на Java 5 JVM