Есть ли польза от обновления скомпилированного кода Java 7 до Java 8?

У меня есть старое приложение, написанное на Java 7. Оно отлично работает в Java 8 JRE. Я не планирую переписывать какой-либо код, чтобы использовать функции Java 8. Есть ли какие-либо технические преимущества в обновлении скомпилированного кода до последней версии Java 8 JDK?

Чтобы было ясно, код в настоящее время скомпилирован с Java 7 и уже работает с последней версией Java 8 JRE. Он уже должен извлечь выгоду из улучшений среды выполнения Java 8. Этот вопрос заключается в том, можно ли получить какие-либо преимущества от компиляции с версией 8 и запуска с компилированным байтовым кодом Java 8.

Кроме того, меня не интересуют нетехнические преимущества, такие как продуктивность разработчика. Я думаю, это важно, но не в этом вопрос. Я прошу ради производственного кода, у которого НЕТ команды разработчиков. Это чисто в режиме обслуживания.

Если я правильно понял вопрос, вы хотите знать, будет ли создаваемый байт-код javac«лучше» в Java 8, чем в Java 7.

Ответ, вероятно, нет, они постоянно исправляют ошибки в компиляторе, и это иногда приводит к более эффективному байт-коду. Но вы не увидите значительного ускорения от этих исправлений для Java 8, насколько я могу судить, в журнале изменений перечислены только 2 основных изменения между версиями.

Веб-сайт оракула ужасен, и я не могу получить список исправлений, связанных с javacмежду версиями, но вот неполный из OpenJDK . Большинство из них, которые мне удается найти, исправляют ошибки. Таким образом, при обновлении до Java 8 есть вероятность, что он больше не будет компилироваться из-за javacболее правильного следования JLS, и в байт-коде будет очень мало «улучшений» или вообще не будет.

Основное преимущество заключается в том, что в Java 8 есть последние исправления ошибок, тогда как Java 7 не обновляется публично.

Кроме того, если вы собираетесь запускать код на Java 8 JVM, у вас может быть установлена ​​только одна версия Java.

Java 8 может быть быстрее и лучше поддерживает новые функции, такие как G1. Однако для вашего варианта использования это может быть медленнее, поэтому единственный способ узнать это - протестировать.

Есть ли какие-либо технические преимущества в обновлении скомпилированного кода до последней версии Java 8 JDK?

Если вы спрашиваете, есть ли польза от повторной компиляции кода Java 7 в компиляторе Java 8, ответ будет; почти ничего.

Единственное небольшое отличие состоит в том, что были незначительные отличия от Java API, поэтому могут быть очень тонкие различия, которые компилятор Java 8 может обнаружить, что Java 7

Другие незначительные отличия - это магическое число в начале файла, возможно, порядок пула констант. Байт-код в основном такой же, даже поддержка, invokedynamicкоторая была добавлена ​​для лямбда-выражений, существовала в Java 7, но просто не использовалась таким образом.

Это может помочь, повышая осведомленность .

При переключении на Java8 вы можете обнаружить, что javac выдает дополнительные предупреждения. Пример: вывод типов был значительно улучшен в Java8. И это может устранить необходимость в аннотациях @SuppressWarnings в вашей текущей кодовой базе (и когда такие аннотации больше не требуются, компилятор предупреждает об этом).

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

С другой стороны:

• Я видел здесь несколько вопросов о (редких) ситуациях, когда Java8 отказывался компилировать код Java7. Таким образом, переход на Java8 также несет (минимальный) риск столкнуться с подобными проблемами.
• И: даже если вы не собираетесь трогать свою кодовую базу сегодня , есть определенная вероятность, что вы передумаете позже. А затем, когда вы не обращаете внимания, вы можете использовать возможности Java8. Что могло усложнить «полевые обновления»; поскольку теперь вам нужно поддерживать две версии исходного кода!
• Затем: в случае, если у вас есть клиенты, использующие продукт, использующий java7 jre; вы должны быть очень осторожны с бинарными исправлениями, которые вы им предоставляете. У нас есть такая установка; и я не раз тратил время зря, потому что случайно поместил один скомпилированный Java8 класс в тестовую систему, управляемую Java7. Этого просто не может произойти, когда ваш разработчик и тестовая / клиентская установка - это все Java7.

Короче говоря: есть несколько тонких преимуществ и определенные риски (где значимость рисков в основном зависит от вашей общей настройки).

Я бы сделал хотя бы по этим фактам.

1) Внутренности HashMap (быстрее под jdk-8)

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

3) Сборщик мусора G1

РЕДАКТИРОВАТЬ

С технической точки зрения это больше похоже на что-то, связанное с Ahead of Time Compilation или что-то, что компилятор может улучшить, больше анализируя код. Насколько я знаю, в компиляторе java 8 такие вещи не выполняются.

С точки зрения разработчика - их много. Повышение продуктивности - это для меня самое главное.

ИЗМЕНИТЬ 2

Я знаю только два момента, которые соответствуют вашему второму запросу:

-параметров

чтобы сохранить имена параметров метода.

-профиль

Называется вариант компактного профиля для меньшей занимаемой площади.

Если у вас нет других причин для перекомпиляции приложения, то это, вероятно, не имеет большого значения, как указано в принятом ответе.

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

• Исходный код вашего приложения совместим с Java 7 и, скорее всего, 8 тоже;
• Если код не компилируется с Java 8, он, вероятно, не будет компилироваться ни с компилятором Java 8 в режиме совместимости -source 7с исходным кодом Java 7 ( с javac);
• Ваши разработчики и CI должны будут запускать модульные и интеграционные тесты для среды выполнения Java 8, чтобы быть как можно ближе к производственной среде. Разработчикам также потребуется запускать приложение в той же среде выполнения Java 8 при его локальном запуске;
• Скомпилировать с JDK 7 и запустить с JRE 8 (в том же процессе сборки или в той же среде IDE) труднее, чем делать все с той же версией;
• Нет никаких преимуществ от использования -source 7вместо, -source 8если вы компилируете с JDK 8 и ваша целевая среда выполнения - Java 8;
• Использование -source 8гарантий того, что разработчик использует Java 8 (или новее) как для компиляции, так и для времени выполнения (в соответствии с требованиями -target 8).

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