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

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

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

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

Во-первых, Sun на самом деле считает все упомянутые вами выпуски (кроме 1.0, конечно) второстепенными, а не основными.

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

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

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

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

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

Каждый выпуск Swing с 1.3 по 1.6 что-то ломал для нас.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующее будет компилироваться под 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";
    }
}

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

• 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?

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

Еще один пример нарушения совместимости java.sql:

В версии 1.5 к java.sql.Timestamp был добавлен метод compareTo (Date). Этот метод вызовет исключение ClassCastException, если предоставленная Date не является экземпляром java.sql.Timestamp. Конечно, java.sql.Timestamp расширяет Date, а Date уже имел метод compareTo (Date), который работал со всеми датами, поэтому это означало, что код, сравнивающий метку времени с датой (без метки времени), сломается во время выполнения в 1.5. .

Интересно отметить, что похоже, что версия 1.6 решила эту проблему. Хотя документация для java.sql.Timestamp.compareTo (Date) по-прежнему говорит: «Если аргумент не является объектом Timestamp, этот метод генерирует объект ClassCastException», фактическая реализация говорит об обратном. Я предполагаю, что это ошибка документации.

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

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

Отчет создается japi-compliance-checker орудие труда.

...

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

Как сказал Шон Рейли, новый метод может сломать ваш код. Помимо простого случая, когда вам нужно реализовать новый метод (это приведет к предупреждению компилятора), есть и худший случай: новый метод в интерфейсе имеет ту же сигнатуру, что и метод, который у вас уже есть. в вашем классе. Единственный намек от компилятора - это предупреждение об отсутствии аннотации @Override (Java 5 для классов, аннотация поддерживается для интерфейсов в Java 6, но не является обязательной).

Я не пробовал, но теоретически это сработает в Java 1.1 и сломается в Java 1.2. (Подробнее здесь)

public class Test {
    float strictfp = 3.1415f;
}

По личному опыту, у нас были некоторые текстовые поля AWT / Swing, встроенные во фрейм SWT_AWT в 1.5, которые перестали быть редактируемыми после обновления до 1.6.