Версията за дългосрочна поддръжка (LTS) на езика Java и платформата за изпълнение Java 17 беше пусната на 14 септември 2021 г. Нека научим какво е новото в Java 17 и дали трябва да надстроите.
Много приложения използват по-стари версии на Java, включително по-ранните LTS версии на Java: 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.
Запечатани класове
Запечатаните класове е функция, която беше въведена в Java 17. Функцията за запечатани класове завърши пробната си фаза и се превърна в официална платформа и език в 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 вече е защитен.
Винаги стриктна семантика с плаваща запетая
Допълнително „премахване“ може да се опише като повторно въвеждане на винаги строга семантика с плаваща запетая. Java 1.2 представи модификации на семантиката с плаваща запетая по подразбиране в Java, която позволява на JVM да търгува с малко количество точност в изчисленията с плаваща запетая, за да подобри производителността. В класове и методи, където трябваше да се използва строга семантика, беше добавена ключова дума strictfp. Оттогава в процесорите бяха въведени различни типове набори от инструкции, което прави използването на строга семантика с плаваща запетая без ненужни разходи. Необходимостта от прилагане на стандартна или строга семантика е елиминирана.
Java 17 премахва предишната семантика по подразбиране и всички операции с плаваща запетая се изпълняват стриктно. Терминът strictf все още присъства. Това обаче няма ефект и предизвиква предупреждение по време на компилиране.
Компилация преди време (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 на аплет
API на Applet най-накрая е определен за премахване от JEP 398, първоначално премахнат в Java 9. Applet API предостави начин за интегриране на Java AWT/Swing контроли в уеб страница в браузър. Въпреки това нито един модерен браузър не може да поддържа това, което означава, че аплетите са били по същество недостъпни през последното десетилетие.
Мениджър по сигурността
Най-важното отхвърляне е, че това е мениджърът на сигурността ( JEP 411). Security Manager се използва известно време от Java 1.0. Той е проектиран да ограничи това, което Java може да прави локално на машината, като например ограничаване на достъпа до мрежи, файлове и други мрежови ресурси. Той също така се опитва да създаде код в пясъчна среда, който не е надежден, като блокира отражението и специфичните API.
Краят на Security Manager започна в Java 12. Беше добавен аргумент от командния ред за блокиране на използването на Security Manager по време на изпълнение. Промяната, направена в Java 17, означава, че предупреждение по време на изпълнение ще бъде генерирано в JVM, когато се опитвате да зададете Security Manager, или от командния ред, или динамично по време на изпълнение.
Инкубатор и функции за преглед
Мнозина се чудеха дали Java 17 ще има някакви функции за предварителен преглед и инкубатор, като се има предвид, че Java 17 беше рекламирана като дългосрочно поддържана версия. Java 17 има два инкубаторни модула и функция за предварителен преглед!
Вектор API
Vector API ( JEP 414) в момента е във втората си фаза на инкубатора. API позволява на разработчиците да дефинират векторно изчисление, което след това JIT компилаторът ще преобразува в подходящата векторна инструкция, поддържана от CPU архитектурата, на която работи JVM (например, използвайки тези от наборите инструкции SSE или AVX).
Преди разработчиците трябваше да използват скаларни функции или да изграждат собствени библиотеки, които бяха специфични за платформата. Внедряването на Vector API в Java също осигурява безпроблемен резервен механизъм, който беше сложен в по-ранните версии.
Стандартизацията на Vector API позволява на класовете в рамките на JDK да го използват. Методите mismatch() на Java Arrays могат да бъдат променени, за да се изпълняват на Java вместо това, елиминирайки изискването за поддържане и писане на множество специфични за платформи реализации в рамките на JVM.
API за външни функции и памет
Допълнителна функция на инкубатора се нарича API за външни функции и памет ( JEP 412). Това е еволюция и сливане на два други инкубаторни модула на Java 16, което е API за чужди връзки ( JEP 389) и API за чужда памет ( JEP 393). И двата предоставят достъп до собствената памет и код чрез използване на статично въведено програмиране, написано на Java.
Съвпадение на шаблони за Switch
Последната характеристика на езиковата предварителна версия, включена в Java 17, е включването на Pattern Matching за 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.";
};
}
Както може би сте забелязали, има декларация на променлива в процеса на проверка. Подобно на другите променливи в Pattern, съвпадението на екземпляр показва, че този обект е проверен от тип и е преобразуван и е достъпен от променливата в рамките на текущата му област.
Функцията за предварителен преглед е още една стъпка към съвпадение на шаблони. Следващата стъпка е да включите способността за деконструиране на масиви и записи.
Трябва ли да надстроите до Java 17?
Да, трябва постоянно да надграждате до най-новата версия, но не веднага след първия ден. Софтуерът и библиотеките, които използвате, може да не са актуализирани, за да включват съвместимост с Java 17, така че може да се наложи да изчакате известно време, докато това стане.
Ако сте останали с LTS версия на Java като Java 8 или Java 11, има множество опции в езика и в самата JVM, които изискват надграждане до Java 17. Тъй като това е версия за дългосрочна поддръжка, има голям шанс вашата производствена среда в крайна сметка също да бъде актуализирана до Java 17.
Ако започвате изцяло нов проект или сте в процес на подготовка и подготовка на вашия проект за Java 17, преминаването към Java 17 по-рано, отколкото по-късно, вероятно е най-ефективният избор, тъй като намалява разходите за преместване. Това също позволява на разработчиците, работещи по проекта, да използват всички най-нови функции и операционната страна.
Можете да се възползвате от многото подобрения, настъпили през последните няколко години, като подобрена поддръжка за контейнери, работещи на Java, както и нови реализации на събирач на отпадъци с ниска латентност.