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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

Я бы сделал, по крайней мере, эти факты.

1) Внутренние элементы HashMap (быстрее в jdk-8)

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

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

EDIT

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

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

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

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

-параметры

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

-profile

Позвонил для параметра "Компактный профиль" для меньшей площади.

Ответ 5

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

Однако, если вам нужно перекомпилировать его даже один раз, подумайте об этом:

• Исходный код приложения совместим с Java 7 и, скорее всего, тоже 8;
• В случае, если код не компилируется с Java 8, он, вероятно, не будет компилироваться ни с компилятором Java 8 в режиме совместимости с исходным кодом Java 7 (-source 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. Не рискуйте иметь ошибку из-за несоответствий среды и не ограничивайте разработчиков без уважительной причины.