Существуют ли конкретные примеры обратной несовместимости между версиями Java?

Question

Были ли несовместимости между выпусками Java, когда исходный код Java / файлы классов Java, ориентированные на версию X Java, не будут компилироваться / выполняться в версии Y (где Y> X)?

Под «выпуском Java» я подразумеваю такие версии, как:

• JDK 1.0 (январь 1996 г.)
• JDK 1.1 (февраль 1997 г.)
• J2SE 1.2 (декабрь 1998 г.)
• J2SE 1.3 (май 2000 г.)
• J2SE 1.4 (февраль 2002 г.)
• J2SE 5.0 (сентябрь 2004 г.)
• Java SE 6 (декабрь 2006 г.)

Правила дома:

• Пожалуйста, включите ссылки и примеры кода, где это возможно.
• Пожалуйста, постарайтесь быть очень конкретным / конкретным в своем ответе.
• Класс, помеченный как @Deprecated, не считается обратной несовместимостью.

Answer 1

Замечания по совместимости для различных версий:

• Java 1.4
• Java 5
• Java 6
• Java 7
• Java 8

Первый серьезный сбой, который я помню, - это введение assert в Java 1.4. Это сильно повлияло на код JUnit .

Answer 2

Прежде всего, Sun фактически рассматривает все упомянутые вами релизы (кроме, конечно, 1.0) как минорные релизы, а не как основные.

Мне не известны какие-либо примеры бинарной несовместимости в то время. Однако было несколько примеров несовместимости источника:

• В Java 5 enum стало зарезервированным словом; это не было раньше Поэтому были исходные файлы, которые использовали enum в качестве идентификатора для компиляции в java 1.4, который не компилировался в java 5.0. Однако вы можете скомпилировать с -source 1.4, чтобы обойти это.

• Добавление методов в интерфейс также может нарушить совместимость с исходным кодом. Если вы реализуете интерфейс, а затем попытаетесь скомпилировать эту реализацию с помощью JDK, который добавляет новые методы к интерфейсу, исходный файл больше не будет успешно компилироваться, поскольку он не реализует всех членов интерфейса. Это часто случалось с java.sql.Statement и другими интерфейсами jdbc. Скомпилированные формы этих «недопустимых» реализаций все еще будут работать, если вы на самом деле не вызовете один из методов, которых не существует; если вы сделаете это, будет выдано исключение MissingMethodException.

Вот несколько примеров, которые я могу вспомнить из макушки головы, могут быть и другие.

Answer 3

Интерфейс java.sql.Connection был расширен с Java 1.5 до Java 1.6, что привело к сбою компиляции всех классов, которые реализовали этот интерфейс.

Answer 4

Каждый выпуск Swing что-то ломал для нас, от 1,3 до 1,6.

Проблема JDBC уже упоминалась, но существующий код сработал.

С 1.5 до 1.6 произошло изменение в поведении Сокета, которое сломало клиент Cisco.

Конечно, были введены новые зарезервированные ключевые слова.

Самым большим, что, на мой взгляд, было непростительно для Солнца, был System.getenv (). Он работал в версии 1.0, а затем был объявлен устаревшим и изменен, чтобы выдавать ошибку на всех платформах под довольно сомнительным обоснованием того, что Mac не имеет системных переменных среды. Затем Mac получил системные переменные окружения, поэтому в 1.5 он был устаревшим и работал. Нет разумных оснований для этого. Верните пустой набор на Mac (у Swing гораздо больше кросс-платформенных проблем, если вы хотите позаботиться об этом уровне кроссплатформенности) или даже на всех платформах.

Я никогда не соглашался с тем, что они отключали эту функцию, но чтобы изменить ее на ошибку, это было просто чистым изменением, и если бы они собирались это сделать, им следовало бы просто полностью удалить метод.

Но на самом деле от 1.0 до 1.1 они были меньше озабочены обратной совместимостью. Например, они удалили «частную защиту» как модификатор.

Итак, в итоге каждая версия изменяется достаточно, чтобы требовать тщательной оценки, поэтому вы все еще видите много вопросов 1.4 здесь, на SO.

Answer 5

Главное, о чем я могу подумать, это введение новых зарезервированных слов:

Java 1.3: strictfp
Java 1.4: assert
Java 5.0: enum

Любой код, который ранее использовал эти значения в качестве идентификаторов, не будет компилироваться в более поздней версии.

Еще одна проблема, которая, как я помню, вызывала проблемы в проекте, над которым я работал, заключалась в том, что изменило видимость JInternalFrames по умолчанию между 1.2 и 1.3 . По умолчанию они были видны, но когда мы обновились до версии 1.3, все они исчезли.

Answer 6

Между 1.3 и 1.4 интерпретация Long.parseLong (String) по-разному обрабатывает пустую строку. 1.3 возвращает значение 0, а 1.4 - NumberFormatException.

Перекомпиляции не нужны, но рабочий код перестал работать, если он опирался на поведение 1.3.

Answer 7

Семантика модели памяти изменена с 1,4 на 1,5 . Он был изменен, чтобы позволить, кроме прочего, дважды проверить блокировку снова. (Я думаю, что изменчивая семантика была исправлена.) Она была нарушена.

Answer 8

Очевидно, что соглашение об именах названий выпусков не обратно совместимо .

• JDK 1.0 (23 января 1996 г.)
• JDK 1.1 (19 февраля 1997 г.)
• J2SE 1.2 (8 декабря 1998 г.)
• J2SE 1.3 (8 мая 2000 г.)
• J2SE 1.4 (6 февраля 2002 г.)
• J2SE 5.0 (30 сентября 2004 г.)
• Java SE 6 (11 декабря 2006 г.)
• Java SE 6, обновление 10, обновление 12, обновление 14, обновление 16
• Java SE 7 ??? JDK7

( Список из Википедии .)

Answer 9

Следующее будет компилироваться под Java 1.4, но не Java 1.5 или более поздняя.

(Java 5 представила enum в качестве ключевого слова. Примечание: он будет компилироваться в Java 5, если указана опция "-source 1.4".)

public class Example {
    public static void main(String[] args) {
        String enum = "hello";
    }
}

Answer 10

См. Отчет об изменениях API для библиотеки классов JRE здесь: http://abi -laboratory.pro / java / tracker / timeline / jre /

Отчет включает анализ обратной совместимости двоичных кодов и исходных кодов классов Java.

Отчет генерируется инструментом japi-Compliance Checker .

...

Еще один интересный анализ для JDK 1.0-1.6 вы можете найти на Japitools JDK-Results page.