Как сказал Шон Рейли, новый метод может взломать ваш код. Помимо простого случая, когда вам нужно реализовать новый метод (это приведет к предупреждению компилятора), есть и худший случай: новый метод в интерфейсе имеет такую ​​же сигнатуру , что и метод, который у вас уже есть в твой класс.

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

public class Test {
    float strictfp = 3.1415f;
}

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

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

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

Следующее будет компилироваться под 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 1.3: strictfp
Java 1.4: assert
Java 5.0: enum

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

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

Прежде всего, 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, что привело к сбою компиляции всех классов, реализующих этот интерфейс.

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

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

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

Каждый выпуск 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 они меньше беспокоились о обратной совместимости. Например, они отказались от модификатора «private protected».

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

Но на самом деле с 1.0 до 1.1 они меньше беспокоились о обратной совместимости. Например, они отказались от модификатора «private protected».

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

Но, на самом деле, с 1.0 до 1.1 они меньше беспокоились о обратной совместимости. Например, они отказались от модификатора «private protected».

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

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