Последствия запуска файла класса Java на разных JRE?

Теоретически ничего. Предполагается, что JVM обратно совместима. Лично у меня никогда не было проблем в этом направлении.

Полностью зависит от того, какие части java-библиотеки вы используете. Это может быть что угодно, от «абсолютно нормально, никакой разницы» до «Боже !! ПОЧЕМУ МОЙ ЖЕСТКИЙ ДИСК ОТФОРМАТИРОВАЛ? (Ну, возможно, не этот второй, но он служит подтверждением того, что он превращается из ничего в возможно плохое :)).

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

AFAIK, однако, байт-код java обратно совместим, поэтому у вас не должно возникнуть никаких проблем с ним, просто ничего не делая.

Он должен работать. Я не помню, чтобы с ним возникали какие-либо проблемы, кроме тех случаев, когда части Java API устарели, и в этом случае он все равно объяснит, что они собой представляют, и вы, надеюсь, сможете написать обходной путь. Конечно, запуск файла класса, скомпилированного с помощью JDK 1.6 в JRE 1.5, вызовет проблему - даже более старые версии JRE, содержащие только незначительные версии сборки, вызовут ошибку.

Одним из положительных последствий является то, что классы 1.4 по-прежнему будут использовать преимущества улучшенной скорости, внесенной в JVM (хотя не обязательно улучшения, внесенные в классы библиотеки).

сам столкнулся с такой проблемой. Я писал код, который должен работать с 1.6, но в колледже была установлена ​​1.3. Многие методы просто не работают, т.е.

input = "" + JOptionPane.showInputDialog (null, "Введите четырехзначное число в" + (b? "encrypt": "decrypt") + ".", (b? "4086": "5317"));

не сработает, но

input = "" + JOptionPane.showInputDialog (null, "Введите четырехзначное число в" + (b? "encrypt": "decrypt") + ".");

бы. метод inputdialog, который принимает три агрумента, не существует в 1.3.

это просто длинный способ сказать, что работа с 1.6 api на 1.3 приводит к инцидентам с ударом головой.

Классы Java совместимы с вперед, например классы, созданные с помощью компилятора 1.5, будут загружены и успешно выполнены без проблем в JRE 1.6. Как правило, ваши классы, созданные сегодняшними компиляторами Java, будут совместимы с будущими JRE (например, Java7).

Обратное неверно: вы не можете запускать классы, созданные с помощью 1.6, на более старых JRE (1.3, 1.4 и т. д.).

Компиляторы Java определяют исходный и целевой уровни соответствия. Таким образом, вы можете скомпилировать любую JRE из любой другой JRE с более высокой версией. Обязательно используйте эти уровни соответствия, потому что между JRE есть различия в API. Например, JRE 1.5 представила StringBuilder на уровне компилятора. Это означает, что каждый раз, когда вы делаете:

String s = "string1" + "string2";

Компилятор изменяет его на:

String s = new StringBuilder("string1").append("string2").toString();

Очевидно, это прервется из-за ошибки NoClassDefFoundError, когда вы попытаетесь создать StringBuilder.

На странице Совместимость с Java SE 6 указана совместимость Jave SE 6 с Java SE 5.0. Кроме того, есть ссылка на Несовместимость в J2SE 5.0 (начиная с 1.4.2). Посмотрев на эти два документа, можно будет выяснить, есть ли несовместимости программ, написанных под JDK 1.4.2 и Java SE 6.

Что касается двоичной совместимости файлов классов Java, на странице совместимости с Java SE 6 говорится следующее:

Java SE 6 is upwards binary-compatible with J2SE 5.0 except for the incompatibilities listed below. Except for the noted incompatibilities, class files built with version 5.0 compilers will run correctly in JDK 6.

Итак, в целом, как заметил workmad3, файлы классов Java, скомпилированные на более старом JDK, по-прежнему будут совместимы с новейшей версией. Более того, как отмечает Desty, любые изменения в API обычно не рекомендуются, а не удаляются.

Из раздела Совместимость источников:

Deprecated APIs are interfaces that are supported only for backwards compatibility. The javac compiler generates a warning message whenever one of these is used, unless the -nowarn command-line option is used. It is recommended that programs be modified to eliminate the use of deprecated APIs, although there are no current plans to remove such APIs entirely from the system with the exception of JVMDI and JVMPI.

В Технический документ о производительности Java SE 6 есть длинный список улучшений производительности.