JDK 16: Nové funkcie v prostredí Java 16

Java Development Kit (JDK) 16 dosiahla svoju počiatočnú fázu znižovania, čo znamená, že sada funkcií je teraz zmrazená, k 10. decembru 2020. Nové funkcie v JDK 16 sa pohybujú od druhého náhľadu zapečatených tried po porovnávanie vzorov so súčasným vláknom - hromadné spracovanie odpadu.

JDK 16 bude referenčnou implementáciou verzie štandardnej Javy, ktorá bude nasledovať po JDK 15, ktorá dorazila 15. septembra. Podľa navrhovaného harmonogramu vydania dosiahne JDK 16 druhú fázu znižovania stavu 14. januára 2021, po ktorej budú kandidáti na vydanie prichádzať 4. februára a 18. februára 2021. Produkčné vydanie má byť zverejnené 16. marca 2021.

Sedemnásť návrhov je oficiálne zameraných na JDK 16 k 10. decembru 2020. Medzi nové funkcie Java 16 patria:

• Návrh varovaní pre triedy založené na hodnotách označuje primitívne obalové triedy ako triedy založené na hodnotách a zastaráva ich konštruktory na odstránenie, čo si vyžiada nové varovania o zastaraní. Poskytujú sa varovania pred nesprávnymi pokusmi o synchronizáciu v inštanciách ľubovoľných tried založených na hodnotách v platforme Java. Hnacím motorom tohto úsilia je projekt Valhalla, ktorý sleduje významné vylepšenie programovacieho modelu Java vo forme primitívnych tried. Primitívne triedy deklarujú inštancie ako bez identity a schopné vložených alebo sploštených reprezentácií, kde je možné inštancie voľne kopírovať medzi pamäťovými miestami a kódovať pomocou hodnôt polí inštancií. Dizajn a implementácia primitívnych tried v Jave je teraz dostatočne vyspelá, aby bolo možné v budúcom vydaní predpokladať migráciu určitých tried platformy Java na primitívne triedy. Kandidáti na migráciu sú v špecifikáciách API neformálne označení ako triedy založené na hodnotách.
• Uzavreté triedy a rozhrania, ktoré boli predtým zobrazené v ukážke JDK 15, obmedzujú, ktoré ďalšie triedy a rozhrania ich môžu rozšíriť alebo implementovať. Medzi ciele plánu patrí umožniť autorovi triedy alebo rozhraniu ovládať kód zodpovedný za jeho implementáciu, poskytnúť deklaratívnejší spôsob ako modifikátory prístupu na obmedzenie používania nadtriedy a podporiť ďalšie smerovanie pri porovnávaní vzorov poskytnutím základu pre analýza vzorov.
• Silné zapuzdrenie interných prvkov JDK v predvolenom nastavení, s výnimkou kritických interných rozhraní API, ako je rôzne. nebezpečné. Používatelia si môžu zvoliť uvoľnenú silnú enkapsuláciu, ktorá je predvolená od JDK 9. Ciele tohto návrhu zahŕňajú zlepšenie bezpečnosti a udržiavateľnosti JDK ako súčasť Project Jigsaw a povzbudenie vývojárov k migrácii z použitia interných prvkov na použitie štandardných API, aby že vývojári aj koncoví používatelia môžu ľahko aktualizovať na budúce vydania Java. Tento návrh so sebou nesie primárne riziko, že sa existujúci kód Java nespustí. Vývojárom sa odporúča, aby pomocou nástroja jdeps identifikovali kód závislý od vnútorných prvkov JDK a prešli na štandardné náhrady, ak sú k dispozícii. Vývojári môžu na testovanie existujúceho kódu pomocou existujúceho vydania, napríklad JDK 11, použiť--illegal-access = varovať na identifikáciu vnútorných prvkov prístupných prostredníctvom reflexie pomocou--illegal-access = ladenie určiť chybný kód a testovať pomocou --illegal-access = odmietnuť.
• Zahraničné linkerové API, ktoré ponúka staticky napísaný, čistý jazyk Java k natívnemu kódu. Toto API bude v štádiu inkubátora v JDK 16. Spolu s navrhovaným API pre prístup do cudzej pamäte, API cudzieho linkera výrazne zjednoduší proces naviazania na natívnu knižnicu, ktorý je inak náchylný na chyby. Tento plán má nahradiť JNI (Java Native Interface) nadradeným vývojovým modelom čistej Javy, ponúknuť podporu C a časom byť dostatočne flexibilný, aby vyhovoval podpore ďalších platforiem, napríklad 32-bit x86, a cudzie funkcie napísané v iných jazykoch ako C, napríklad C ++. Výkon by mal byť lepší alebo porovnateľný s JNI.
• Presunutie spracovania zásobníka vlákien ZGC (Z Garbage Collector) z bezpečných bodov do súbežnej fázy. Ciele tohto plánu zahŕňajú odstránenie spracovania vlákien z bezpečnostných bodov ZGC; vďaka čomu je stohové spracovanie lenivé, kooperatívne, súbežné a prírastkové; odstránenie všetkého ostatného spracovania koreňov na vlákno zo ZPC bezpečných bodov; a poskytnutie mechanizmu pre ďalšie subsystémy HotSpot VM na lenivé spracovanie zásobníkov. Zámerom ZGC je, aby sa pauzy GC a problémy so škálovateľnosťou v HotSpote stali minulosťou. Doteraz boli operácie GC, ktoré sa zväčšujú s veľkosťou haldy a veľkosťou metaspace, presunuté z operácií bezpečného bodu do súbežných fáz. Medzi ne patrilo značenie, premiestnenie, spracovanie odkazov, vyloženie triedy a väčšina spracovania root. Jediné činnosti, ktoré sa v bodoch GC stále vykonávajú, sú podmnožina spracovania koreňov a časovo ohraničená operácia ukončenia značenia. Medzi tieto korene patria súbory vlákien Java a ďalšie korene vlákien, pričom tieto korene sú problematické, pretože sa zväčšujú počtom vlákien. Aby sme prekonali súčasnú situáciu, musí sa spracovanie na jedno vlákno vrátane skenovania zásobníka presunúť do súbežnej fázy. S týmto plánom by náklady na priechod vylepšenej latencie mali byť zanedbateľné a čas strávený vo vnútri bezpečných bodov ZGC na typických strojoch by mal byť menej ako jedna milisekunda.
• Elastická funkcia metaspace, ktorá vracia nepoužitú pamäť metadát (metaspace) triedy HotSpot VM triedy rýchlejšie do operačného systému, znižuje stopu metaspace a zjednodušuje metaspace kód, aby sa znížili náklady na údržbu. Metaspace mal problémy s využívaním vysokej hromady pamäte. Plán vyžaduje nahradenie existujúceho alokátora pamäte schémou alokovania na základe kamaráta, čo poskytuje algoritmus na rozdelenie pamäte na oddiely, aby sa uspokojili pamäťové požiadavky. Tento prístup sa používal na miestach, ako je jadro Linuxu, a umožní praktické alokovať pamäť v menších blokoch, aby sa znížila réžia triedy-loader. Fragmentácia sa tiež zníži. Okrem toho sa vyhradenie pamäte od operačného systému k arénam správy pamäte bude robiť lenivo, na požiadanie, aby sa znížila stopa pre nakladače, ktoré začínajú s veľkými arénami, ale nepoužívajú ich okamžite alebo ich možno nevyužívajú v plnom rozsahu. Aby sa plne využila pružnosť, ktorú ponúka alokácia kamarátov, bude metaspace pamäť usporiadaná do rovnomerne veľkých granúl, ktoré môžu byť odovzdávané a zrušené nezávisle od seba.
• Povolenie funkcií jazyka C ++ 14, aby sa umožnilo použitie funkcií C ++ 14 v zdrojovom kóde JDK C ++, a poskytnutie konkrétneho usmernenia o tom, ktoré z týchto funkcií sa môžu použiť v kóde VM HotSpot. Prostredníctvom JDK 15 boli jazykové funkcie používané kódom C ++ v JDK obmedzené na jazykové štandardy C ++ 98/03. S JDK 11 bol zdrojový kód aktualizovaný tak, aby podporoval vytváranie s novšími verziami štandardu C ++. To zahŕňa schopnosť zostavovať s najnovšími verziami kompilátorov, ktoré podporujú funkcie jazyka C ++ 11/14. Tento návrh nenavrhuje žiadne zmeny štýlu alebo použitia kódu C ++, ktorý sa používa mimo HotSpot. Aby ste však mohli využiť výhody funkcií jazyka C ++, sú potrebné určité zmeny v čase zostavenia, v závislosti od kompilátora platformy.
• Vektorové API v inkubačnej fáze, v ktorej by bola JDK vybavená inkubačným modulom, jdk.incubator.vector, na vyjadrenie vektorových výpočtov, ktoré sa kompilujú na optimálne vektorové hardvérové ​​pokyny na podporovaných architektúrach CPU, na dosiahnutie lepšieho výkonu ako ekvivalentné skalárne výpočty. Vektorové API poskytuje mechanizmus na zápis zložitých vektorových algoritmov v Jave, ktorý využíva už existujúcu podporu vo vektore HotSpot VM na vektorizáciu, ale s užívateľským modelom, vďaka ktorému je vektorizácia predvídateľnejšia a robustnejšia. Ciele návrhu zahŕňajú poskytnutie jasného a výstižného rozhrania API na vyjadrenie celého radu vektorových výpočtov, zvýšenie agnostiky platformy na podporu viacerých architektúr CPU a ponúknutie spoľahlivej runtime kompilácie a výkonu na architektúrach x64 a AArch64. Ladná degradácia je tiež cieľ, pri ktorom by sa vektorový výpočet ladne degradoval a stále by fungoval, ak by sa za behu nedá úplne vyjadriť ako postupnosť hardvérových vektorových pokynov, buď preto, že architektúra nepodporuje niektoré pokyny, alebo nie je podporovaná iná architektúra CPU. .
• Portovanie JDK na platformu Windows / AArch64. S vydaním nového serverového a spotrebného hardvéru AArch64 (ARM64) sa Windows / AArch64 stali dôležitou platformou kvôli dopytu. Aj keď samotné portovanie je už väčšinou hotové, zameranie tohto návrhu spočíva v integrácii portu do hlavného úložiska JDK.
• Portovanie JDK na Alpine Linux a na ďalšie distribúcie Linuxu, ktoré používajú musl ako svoju primárnu knižnicu C, na architektúrach x64 a AArch64. Musl je implementácia štandardnej knižničnej funkcionality opísanej v normách ISO C a Posix v systéme Linux. Alpine Linux je vďaka svojej malej veľkosti obrazu široko používaný v cloudových implementáciách, mikroslužbách a kontajnerovom prostredí. Obrázok doku pre systém Linux je menší ako 6 MB. Ak v takýchto nastaveniach necháte Java bežať priamo z krabice, umožníte tým Tomcat, Jetty, Spring a ďalším populárnym rámcom natívne pracovať v týchto prostrediach. Použitím jlink na zmenšenie veľkosti runtime Java môže užívateľ vytvoriť ešte menší obraz prispôsobený na spustenie konkrétnej aplikácie.
• Poskytovanie tried záznamov, ktoré fungujú ako transparentní nosiči nemenných údajov. Záznamy možno považovať za nominálne n-tice. Zobrazenie ukážok záznamov bolo v JDK 14 a JDK 15. Táto snaha je reakciou na sťažnosti, že Java bola príliš podrobná alebo bola príliš slávnostná. Medzi ciele plánu patrí navrhnutie objektovo orientovaného konštruktu, ktorý vyjadruje jednoduchú agregáciu hodnôt, pomoc vývojárom zamerať sa skôr na modelovanie nemenných údajov ako na rozšíriteľné správanie, automatická implementácia metód založených na dátach, ako napr. rovná sa a prístupových práv a zachovanie dlhodobých princípov Java, ako je nominálne písanie.
• Pridanie soketových kanálov domén Unix, v ktorých je pridaná podpora soketov domén Unix (AF_UNIX) do API soketových kanálov a serverových soketových kanálov v balíku nio.channels. Plán tiež rozširuje zdedený mechanizmus kanálov na podporu soketových kanálov domén Unix a soketových kanálov servera. Zásuvky domény Unix sa používajú na medziprocesovú komunikáciu na rovnakom hostiteľovi. Vo väčšine ohľadov sú podobné zásuvkám TCP / IP, až na to, že sú adresované skôr názvami ciest súborového systému ako IP adresami a číslami portov. Cieľom novej funkcie je podpora všetkých funkcií soketových kanálov domén Unix, ktoré sú spoločné naprieč hlavnými platformami Unix a Windows. Unixové doménové kanály soketov sa budú chovať rovnako ako existujúce kanály TCP / IP, pokiaľ ide o správanie pri čítaní a zápise, nastavenie spojenia, prijímanie prichádzajúcich pripojení servermi a multiplexovanie s inými neblokujúcimi voliteľnými kanálmi v selektore. Zásuvky domény Unix sú bezpečnejšie a efektívnejšie ako spätné pripojenie TCP / IP pre miestnu medziprocesovú komunikáciu.
• Rozhranie API na prístup do cudzej pamäte, ktoré umožňuje programom Java bezpečný prístup k cudzej pamäti mimo haldy Java. Predtým inkubované v JDK 14 aj JDK 15, API pre prístup do cudzej pamäte by bolo znovu inkubované v JDK 16, čím by sa pridali vylepšenia. Urobili sa zmeny vrátane jasnejšieho rozdelenia rolí medzi MemorySegment a Pamäťové adresy rozhrania. Ciele tohto návrhu zahŕňajú poskytnutie jediného rozhrania API na prácu s rôznymi druhmi cudzej pamäte, vrátane natívnej, trvalej a spravovanej haldy pamäte. API by nemalo narušiť bezpečnosť JVM. Návrh motivuje skutočnosť, že mnoho programov Java pristupuje k cudzej pamäti, napríklad Ignite, Memcached a MapDB. Ale Java API neposkytuje uspokojivé riešenie pre prístup do cudzej pamäte.
• Zhoda vzorov pre inštancia operátor, ktorého ukážka bola tiež zobrazená v JDK 14 aj JDK 15. Dokončená by bola v JDK 16. Porovnávanie vzorov umožňuje výstižnejšie a bezpečnejšie vyjadrenie bežnej logiky v programe, konkrétne podmienenej extrakcie komponentov z objektov.
• Poskytovanie nástroja jpackage na balenie samostatných aplikácií Java. Program jpackage, ktorý bol predstavený ako inkubačný nástroj v JDK 14, zostal v inkubácii v JDK 15. S JDK 16 sa jpackage presúva do výroby a podporuje natívne formáty balíkov, aby používateľom poskytli prirodzený zážitok z inštalácie a umožnili špecifikáciu parametrov času spustenia v čase balenia. Formáty zahŕňajú msi a exe v systéme Windows, pkg a dmg v systéme MacOS a deb a rpm v systéme Linux. Nástroj je možné vyvolať priamo z príkazového riadku alebo programovo. Nový nástroj na balenie rieši situáciu, v ktorej je veľa aplikácií Java potrebné inštalovať na natívne platformy prvotriednym spôsobom, namiesto toho, aby boli umiestnené na cestu triedy alebo cestu modulu. Potrebný je nainštalovateľný balík vhodný pre natívnu platformu.
• Migrácia úložísk zdrojových kódov OpenJDK z Mercurialu do Gitu. Toto úsilie vedie k výhodám vo veľkosti metadát systému riadenia verzií a dostupných nástrojoch a hostovaní.
• Migrácia na GitHub súvisiaca s migráciou Mercurial-to-Git, pričom úložiská zdrojových kódov JDK 16 sa nachádzajú na populárnej stránke na zdieľanie kódov. Súčasťou tohto plánu by boli vydania funkcií JDK a vydania aktualizácií JDK pre Java 11 a novšie verzie. Prechod na Git, GitHub a Skara pre Mercurial JDK a JDK-sandbox sa uskutočnil 5. septembra a je otvorený pre príspevky.

Zostavenia JDK 16 pre včasný prístup pre Linux, Windows a MacOS nájdete na jdk.java.net. Rovnako ako JDK 15, aj JDK 16 bude predstavovať krátkodobé vydanie podporované šesť mesiacov. JDK 17, ktorá sa má vydať v septembri 2021, bude vydaním dlhodobej podpory (LTS), na ktoré bude poskytnutá niekoľkoročná podpora. Aktuálne vydanie LTS, JDK 11, bolo vydané v septembri 2018.