Версія довгострокової підтримки (LTS) мови Java та платформи виконання Java 17 була запущена 14 вересня 2021 року. Давайте дізнаємося, що нового в Java 17 і чи варто оновлюватися.
Багато програм використовують старіші версії Java, включно з попередніми версіями Java LTS: Java 11 і Java 8.
Чому компаніям варто оновити Java до останньої версії? Оновлення до Java 17 вимагає зусиль, головним чином для максимального використання нових можливостей і функцій у JVM.
Багато компаній використовують Docker і образи Docker, щоб легко перейти на Java 17 з мінімальними зусиллями та часом. Розробники можуть визначати свої конвеєри безперервної інтеграції/розгортання (CI/CD) і запускати все в образах Docker. Це не вплине на інші команди, які використовують старіші версії Java, оскільки вони можуть використовувати старі образи Docker.
Особливості JAVA 17
Підтримка macOS і AArch64
Однією з важливих функцій JVM, доданих до цієї версії, є покращена підтримка macOS на архітектурі AArch64 за допомогою JEP 391. Вона підтримуватиме останню серію процесорів (M1), випущених Apple на своїх комп’ютерах минулого року.
Це не обов’язково є великою проблемою для користувачів на цих платформах, оскільки деякі постачальники запустили версії JDK, які підтримують цю архітектуру та навіть повернули підтримку з Java 8. Однак офіційна печатка схвалення є важливою для забезпечення майбутнього обслуговування та підтримки платформа. Для порівняння, підтримку платформи Linux/AArch64 додано до Java 9 і Windows/AArch64 у Java 16.
Запечатані класи
Sealed Classes — це функція, представлена в Java 17. Функція sealed Classes завершила свою пробну фазу та стала офіційною платформою та мовою в Java 17. Вона дозволяє розробнику вказувати допустимі підтипи, які може мати тип, і перешкоджати іншим розширювати або впроваджувати його не за призначенням.
Запечатані класи також дозволяють компілятору генерувати помилки під час компіляції, коли ви намагаєтеся перетворити незапечатаний тип на недозволений підтип. Java 17 також пропонує новий конвеєр візуалізації для програм AWT/Swing, які працюють на macOS з використанням Apple Metal API замість OpenGL. Він має покращений API та вдосконалені функції для генерації випадкових чисел.
Зміни, видалення та обмеження в Java 17
Java 17 також приносить кілька змін, видалень і нових обмежень.
Інкапсуляція внутрішніх елементів JDK
Однією зміною є завершення процесу інкапсуляції JDK Internals. Вперше це було введено в Java 9 і давало попередження під час виконання, коли користувач намагався використати відображення чи щось подібне, щоб обійти звичайні обмеження на використання внутрішніх API. Для регулювання такої поведінки також додано аргументи командного рядка.
Починаючи з Java 9, було створено різні API, щоб запропонувати єдиний спосіб виконання завдань, які найчастіше використовуються; користувачі будуть використовувати ці API всередині. У Java 16 значення за замовчуванням було змінено з попередження на вимкнення доступу до створення винятку. Однак він використовує аргумент командного рядка, щоб змінити поведінку.
У Java 17 аргумент командного рядка вилучено, і це обмеження можна вимкнути. Це означає, що весь неавторизований доступ до цих внутрішніх API тепер захищено.
Завжди строга семантика з плаваючою комою
Додаткове «видалення» можна описати як повторне введення семантики Always-Strict Floating Point. Java 1.2 представила модифікації семантики з плаваючою комою за замовчуванням у Java, що дозволяє JVM торгувати невеликою кількістю точності в обчисленнях з плаваючою комою для підвищення продуктивності. У класах і методах, де повинна була використовуватися сувора семантика, було додано ключове слово strictfp. Відтоді до ЦП було введено різні типи наборів інструкцій, завдяки чому сувора семантика з плаваючою комою може використовуватися без зайвих витрат. Потреба в реалізації стандартної або суворої семантики була усунена.
Java 17 видаляє попередню семантику за замовчуванням, і всі операції з плаваючою комою виконуються строго. Термін strictfpis все ще існує. Однак це не має ефекту та викликає попередження під час компіляції.
Попередня компіляція (AOT).
Java 9 представила компіляцію наперед (AOT) як експериментальну функцію, яка використовує компілятор Graal, і JIT-код був написаний за допомогою Java. Java 10 зробила компілятор Graal придатним для використання як JIT-компілятор у OpenJDK, включивши інтерфейс JVMCI. Відтоді як він був випущений, він значно покращився. Компілятор Graal досяг величезних успіхів і має свою JVM під назвою GraalVM.
Активація RMI
Активація RMI була ліквідована в JEP 407 після його видалення з Java 8 і, нарешті, застарілого та позначеного як вимога для видалення в Java 15. Активація RMI надала метод для ввімкнення ресурсів розподілених об’єктів на вимогу за допомогою RMI. Однак він використовувався мінімально, і зараз доступна краща альтернатива. На решту RMI не впливає видалення частини активації.
Видалення API аплетів
Applet API нарешті призначено для видалення JEP 398, спочатку видалений у Java 9. Applet API надав спосіб інтегрувати елементи керування Java AWT/Swing у веб-сторінку в браузері. Однак жоден сучасний браузер не підтримує це, а це означає, що аплети були практично недоступні протягом останнього десятиліття або близько того.
Менеджер безпеки
Найважливішим застарілим є менеджер безпеки ( JEP 411). Менеджер безпеки використовується деякий час, починаючи з Java 1.0. Він був розроблений для обмеження того, що Java може робити локально на машині, наприклад обмеження доступу до мереж, файлів та інших мережевих ресурсів. Він також намагається створити ненадійний код ізольованого середовища, блокуючи відображення та певні API.
Кінець диспетчера безпеки почався в Java 12. Було додано аргумент командного рядка, щоб блокувати використання диспетчера безпеки під час виконання. Зміни, внесені в Java 17, означають, що під час спроби встановити диспетчер безпеки з командного рядка або динамічно під час виконання у JVM буде створено попередження під час виконання.
Інкубатор і функції попереднього перегляду
Багатьох цікавило, чи матиме Java 17 будь-які функції попереднього перегляду та інкубатора, враховуючи, що Java 17 була розроблена як версія з довгостроковою підтримкою. Java 17 має два модулі інкубатора та функцію попереднього перегляду!
Vector API
Vector API ( JEP 414) зараз перебуває на другому етапі інкубатора. API дозволяє розробникам визначати векторне обчислення, яке JIT-компілятор потім перетворить у відповідну векторну інструкцію, підтримувану архітектурою ЦП, на якій працює JVM (наприклад, використовуючи набори інструкцій SSE або AVX).
Раніше розробникам доводилося використовувати скалярні функції або створювати рідні бібліотеки, які були специфічні для платформи. Реалізація Vector API у Java також забезпечує плавний резервний механізм, який був складним у попередніх версіях.
Стандартизація Vector API дозволяє використовувати його класам у JDK. Методи Java Arrays mismatch() можуть бути змінені для запуску на Java, усуваючи вимогу підтримувати та писати декілька специфічних для платформ реалізацій у JVM.
API зовнішніх функцій і пам’яті
Додаткова функція інкубатора називається API зовнішньої функції та пам’яті ( JEP 412). Це еволюція та злиття двох інших модулів-інкубаторів Java 16, тобто The Foreign Linker API ( JEP 389) і API зовнішньої пам’яті ( JEP 393). Обидва вони надають доступ до власної пам’яті та коду за допомогою статично типізованого програмування, написаного на Java.
Зіставлення шаблонів для Switch
Останньою функцією попереднього перегляду мови, включеної в Java 17, є включення зіставлення шаблонів для Switch ( JEP 406). Ця мовна функція розширює вирази перемикання та оператори відповідно до типу, подібно до синтаксису, який використовується через зіставлення шаблонів (JEP 394), яка стала стандартною з Java 16.
Раніше, якщо ви хотіли виконувати різні дії на основі динамічної природи об’єкта, вам потрібно було побудувати ланцюжок if-else за допомогою екземпляра перевірок, наприклад:
String type(Object o) {
if (o instanceof List) {
return "A List of things.";
}
else if (o instanceof Map) {
return "A Map! It has keys and values.";
}
else if (o instanceof String) {
return "This is a string.";
}
else {
return "This is something else.";
}
}
Поєднавши вираз перемикача, а також нову функцію зіставлення шаблонів для перемикачів, процес можна звести до чогось подібного до:
String type(Object o) {
return switch (o) {
case List l -> "A List of things.";
case Map m -> "A Map! It has keys and values.";
case String s -> "This is a string.";
default -> "This is something else.";
};
}
Як ви могли помітити, у процесі перевірки є оголошення змінної. Подібно до інших змінних у шаблоні, відповідність екземпляру вказує на те, що цей об’єкт був перевірений типом і приведений, і він доступний зі змінної в межах його поточної області.
Функція попереднього перегляду є ще одним кроком до зіставлення шаблонів. Наступним кроком є включення можливості деконструювання масивів і записів.
Чи варто оновлюватися до Java 17?
Так, ви повинні постійно оновлюватися до найновішої версії, але не відразу з першого дня. Можливо, програмне забезпечення та бібліотеки, які ви використовуєте, не були оновлені для сумісності з Java 17, тому вам може знадобитися деякий час почекати, поки це буде зроблено.
Якщо ви застрягли на LTS-версії Java, як-от Java 8 або Java 11, існує багато варіантів у мові та в самій JVM, які вимагають оновлення до Java 17. Оскільки це версія для довгострокового обслуговування, є велика ймовірність того, що ваше виробниче середовище також буде оновлено до Java 17.
Якщо ви починаєте абсолютно новий проект або перебуваєте в процесі підготовки свого проекту до Java 17, скоріше перейти на Java 17, мабуть, найефективніший вибір, оскільки це зменшує витрати на переїзд. Це також дозволяє розробникам, які працюють над проектом, використовувати всі найновіші функції та операційну сторону.
Ви можете скористатися багатьма вдосконаленнями, які відбулися за останні кілька років, наприклад покращеною підтримкою контейнерів, що працюють на Java, а також новими реалізаціями збирача сміття з низькою затримкою.