Чи є якась користь від оновлення компільованого коду 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 основні зміни між версіями.

Веб-сайт oracle жахливий, і я не можу отримати список помилок, пов’язаних javacміж версіями, але ось OpenJDK не є вичерпним . Більшість із тих, кому я вдається знайти, - це виправлення помилок. Таким чином, оновивши Java 8, є ймовірність, що він більше не буде компілюватися завдяки javacправильнішому слідуванню за JLS, і "покращень" байт-коду буде зовсім мало.

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

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

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

Чи є якась технічна вигода від оновлення складеного коду до останнього Java 8 JDK?

Якщо ви запитуєте, чи є користь у перекомпіляції коду Java 7 у компіляторі Java 8, відповідь є; майже нічого.

Єдина тонка різниця полягає в тому, що в API Java були незначні відмінності, тому можуть бути дуже тонкі відмінності, що компілятор 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

EDIT

З технічної точки зору це звучить більше як щось, що стосується компіляції перед часом або щось, що компілятор може покращити, аналізуючи код більше. Наскільки мені відомо, такі речі не робляться в компіляторі java 8.

З точки зору розробника - є багато. Підвищення продуктивності є найважливішим для мене.

EDIT 2

Я знаю лише два моменти, які відповідають вашому другому запиту:

–Параметри

щоб зберегти імена параметрів методу.

-профіль

Викликається компактний варіант профілю для меншої площі.

Якщо у вас немає інших причин перекомпілювати свою заявку, то, ймовірно, це не має великого значення, як зазначено у прийнятій відповіді.

Однак якщо вам доведеться перекомпілювати його лише один раз, врахуйте це:

• Ваш вихідний код програми сумісний з 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. Не ризикуйте виникнути помилку через невідповідність середовища та не обмежуйте розробників без поважних причин.