JDK 16: Nové funkce v prostředí Java 16

Java Development Kit (JDK) 16 dosáhla své počáteční fáze rampdownu, což znamená, že sada funkcí je nyní zmrazena, k 10. prosinci 2020. Nové funkce v JDK 16 se pohybují od druhého náhledu zapečetěných tříd po porovnávání vzorů se souběžným vláknem - zpracování zásobníku pro sběr odpadu.

JDK 16 bude referenční implementací verze standardní Javy, která bude následovat JDK 15, která dorazila 15. září. Navrhovaný plán vydání má JDK 16 dosáhnout druhé fáze rampdownu 14. ledna 2021, po níž budou následovat kandidáti na vydání 4. února a 18. února 2021. Vydání produkce má být vydáno 16. března 2021.

Sedmnáct návrhů se oficiálně zaměřuje na JDK 16 k 10. prosinci 2020. Mezi nové funkce přicházející do prostředí Java 16 patří:

• Varování pro návrh tříd založených na hodnotách označuje třídy primitivního obálky jako založené na hodnotách a odmítá jejich konstruktory k odebrání, což vyvolá nová upozornění na odmítnutí. Jsou poskytována varování ohledně nesprávných pokusů o synchronizaci v instancích libovolných tříd založených na hodnotách v platformě Java. Hnací silou tohoto úsilí je projekt Valhalla, který sleduje významné vylepšení programovacího modelu Java v podobě primitivních tříd. Primitivní třídy deklarují instance jako bez identity a schopné inline nebo zploštělých reprezentací, kde lze instance volně kopírovat mezi paměťovými místy a kódovat pomocí hodnot polí instancí. Návrh a implementace primitivních tříd v jazyce Java je nyní dostatečně vyspělý, takže v budoucím vydání lze očekávat migraci určitých tříd platformy Java na primitivní třídy. Kandidáti na migraci jsou ve specifikacích API neformálně označeni jako třídy založené na hodnotách.
• V předchozím náhledu v JDK 15 uzavřené třídy a rozhraní omezují, které další třídy a rozhraní je mohou rozšířit nebo implementovat. Cíle plánu zahrnují umožnit autorovi třídy nebo rozhraní ovládat kód odpovědný za jeho implementaci, poskytnout deklarativnější způsob než modifikátory přístupu k omezení použití nadtřídy a podporovat budoucí směry v porovnávání vzorů poskytnutím základu pro analýza vzorů.
• Ve výchozím nastavení silné zapouzdření interních prvků JDK, s výjimkou kritických interních rozhraní API, jako je různé. nebezpečné. Uživatelé si mohou vybrat uvolněné silné zapouzdření, které je výchozím nastavením od JDK 9. Cíle tohoto návrhu zahrnují zlepšení zabezpečení a udržovatelnosti JDK jako součásti Project Jigsaw a povzbuzení vývojářů k migraci z používání interních prvků na používání standardních API, aby že vývojáři i koncoví uživatelé mohou snadno aktualizovat na budoucí vydání Java. Tento návrh nese primární riziko, že se stávající kód Java nezdaří. Vývojářům se doporučuje používat nástroj jdeps k identifikaci kódu, který závisí na interních prvcích JDK, a přejít na standardní náhrady, pokud jsou k dispozici. Vývojáři mohou použít existující verzi, jako je JDK 11, k testování existujícího kódu pomocí--illegal-access = varovat identifikovat vnitřní prvky přístupné pomocí reflexe, pomocí--illegal-access = debug určit chybný kód a testování pomocí --illegal-access = odepřít.
• Zahraniční linker API, nabízející staticky napsaný, čistý-Java přístup k nativnímu kódu. Toto API bude ve fázi inkubátoru v JDK 16. Spolu s navrhovaným API pro přístup do cizí paměti, API cizího linkeru výrazně zjednoduší proces vázání k nativní knihovně, který je jinak náchylný k chybám. Tento plán má nahradit JNI (Java Native Interface) nadřazeným vývojovým modelem čisté Javy, nabídnout podporu jazyka C a časem být dostatečně flexibilní, aby vyhověl podpoře dalších platforem, jako je 32bitová verze x86, a cizí funkce napsané v jiných jazycích než C, například C ++. Výkon by měl být lepší než nebo srovnatelný s JNI.
• Přesunutí zpracování podprocesů ZGC (Z Garbage Collector) z bodů zabezpečení do souběžné fáze. Cíle tohoto plánu zahrnují odebrání zpracování podprocesů z bodů ZGC; učinit zpracování zásobníku líné, kooperativní, souběžné a přírůstkové; odebrání veškerého dalšího zpracování kořenů na vlákno z bodů ZGC; a poskytnutí mechanismu pro další subsystémy HotSpot VM pro líné zpracování zásobníků. ZGC má za cíl učinit pauzy GC a problémy se škálovatelností v HotSpotu minulostí. Zatím byly operace GC, které se zvětšují s velikostí haldy a velikostí metaspace, přesunuty z operací bezpečného bodu a do souběžných fází. Mezi ně patří značení, přemístění, zpracování referencí, vykládání tříd a většina zpracování kořenů. Jedinými aktivitami, které se stále provádějí v bodech zabezpečení GC, je podmnožina zpracování kořenů a časově omezená operace ukončení značení. Mezi tyto kořeny patří hromádky podprocesů Java a další kořeny podprocesů, přičemž tyto kořeny jsou problematické, protože se mění s počtem podprocesů. Chcete-li přejít za současnou situaci, musí se zpracování na jedno vlákno, včetně skenování zásobníku, přesunout do souběžné fáze. S tímto plánem by náklady na propustnost vylepšené latence měly být zanedbatelné a čas strávený uvnitř bodů ZGC bezpečných na typických počítačích by měl být méně než jedna milisekunda.
• Funkce elastického metaspace, která do operačního systému pohotově vrací nepoužívanou paměť metadat (metaspace) třídy HotSpot VM, snižuje stopu metaspace a zjednodušuje kód metaspace, aby se snížily náklady na údržbu. Metaspace měl problémy s velkým využitím mezipaměti paměti. Plán volá po nahrazení stávajícího alokátoru paměti alokačním schématem založeným na kamarádech, což poskytuje algoritmus pro rozdělení paměti na oddíly, aby byly uspokojeny požadavky na paměť. Tento přístup byl použit na místech, jako je linuxové jádro, a bude praktické přidělit paměť na menší bloky, aby se snížila režie třídy-loader. Fragmentace bude také snížena. Kromě toho bude nasazení paměti z OS do arén správy paměti prováděno líně, na vyžádání, aby se snížila stopa pro zavaděče, které začínají s velkými arénami, ale nepoužívají je okamžitě nebo je nemusí využívat v plném rozsahu. Aby bylo možné plně využít pružnost nabízenou přidělením kamarádů, bude paměť metaspace uspořádána do rovnoměrně velkých granulí, které lze nezávisle na sobě zavázat a zrušit.
• Povolení funkcí jazyka C ++ 14, aby bylo možné využívat funkce C ++ 14 ve zdrojovém kódu JDK C ++ a poskytnout konkrétní pokyny o tom, které z těchto funkcí lze použít v kódu HotSpot VM. Prostřednictvím JDK 15 byly jazykové funkce používané kódem C ++ v JDK omezeny na jazykové standardy C ++ 98/03. S JDK 11 byl zdrojový kód aktualizován, aby podporoval vytváření s novějšími verzemi standardu C ++. To zahrnuje schopnost sestavovat s nejnovějšími verzemi překladačů, které podporují funkce jazyka C ++ 11/14. Tento návrh nenavrhuje žádné změny stylu nebo použití kódu C ++, který se používá mimo HotSpot. Abychom však mohli využívat výhod funkcí jazyka C ++, jsou vyžadovány některé změny v době sestavení, v závislosti na kompilátoru platformy.
• Vektorové API ve fázi inkubátoru, ve kterém by byl JDK vybaven inkubačním modulem, jdk.incubator.vector, k vyjádření vektorových výpočtů, které se kompilují podle optimálních vektorových hardwarových pokynů na podporovaných architekturách CPU, k dosažení vyššího výkonu jako u ekvivalentních skalárních výpočtů. Vektorové API poskytuje mechanismus pro zápis složitých vektorových algoritmů v Javě, který využívá již existující podporu ve VM HotSpot pro vektorizaci, ale s uživatelským modelem, díky kterému je vektorizace předvídatelnější a robustnější. Cíle návrhu zahrnují poskytnutí jasného a stručného rozhraní API pro vyjádření řady vektorových výpočtů, agnostika platformy podporující více architektur CPU a nabídka spolehlivé běhové kompilace a výkonu na architekturách x64 a AArch64. Graceful degradation also is a goal, in which a vector computation would degradate gracefully and still function if it cannot be fully identified at runtime as a sequence of hardware vector instructions, either because an architecture does not support some instructions or another CPU architecture is not supported .
• Portování JDK na platformu Windows / AArch64. S vydáním nového serverového a spotřebitelského hardwaru AArch64 (ARM64) se Windows / AArch64 staly důležitou platformou kvůli poptávce. Zatímco samotné portování je již většinou dokončeno, zaměřuje se tento návrh na integraci portu do hlavního úložiště JDK.
• Portování JDK na Alpine Linux a na další distribuce Linuxu, které používají musl jako svoji primární knihovnu C, na architekturách x64 a AArch64. Musl je implementace standardní funkce knihovny v systému Linux popsaná ve standardech ISO C a Posix. Alpine Linux je díky své malé velikosti obrazu široce přijímán v cloudových implementacích, mikroslužbách a prostředích kontejnerů. Obrázek Dockeru pro Linux je menší než 6 MB. Pokud necháte Java v takovém nastavení běžet ihned po vybalení, umožníte Tomcat, Jetty, Spring a dalším populárním frameworkům nativně pracovat v těchto prostředích. Pomocí jlink ke zmenšení velikosti běhového prostředí Java může uživatel vytvořit ještě menší obrázek přizpůsobený pro spuštění konkrétní aplikace.
• Poskytování tříd záznamů, které fungují jako transparentní nosiče neměnných dat. Záznamy lze považovat za nominální n-tice. Náhledy záznamů byly zobrazeny v JDK 14 a JDK 15. Toto úsilí je reakcí na stížnosti, že Java byla příliš podrobná nebo má příliš velký ceremoniál. Cíle plánu zahrnují vytvoření objektově orientovaného konstruktu, který vyjadřuje jednoduchou agregaci hodnot, pomáhá vývojářům soustředit se spíše na modelování neměnných dat než na rozšiřitelné chování a automaticky implementovat metody založené na datech, jako je například se rovná a přistupující osoby a zachování dlouhodobých principů Java, jako je nominální psaní.
• Přidání kanálů soketů domén Unix, ve kterých je přidána podpora soketů domén Unix (AF_UNIX) do rozhraní API kanálů soketů a serverů soketů kanálu v balíčku nio.channels. Plán také rozšiřuje mechanismus zděděného kanálu na podporu kanálů soketů domény Unix a kanálů soketů serveru. Zásuvky domény Unix se používají pro komunikaci mezi procesy na stejném hostiteli. Ve většině ohledů jsou podobné soketům TCP / IP kromě toho, že jsou adresovány spíše cestou cesty k souborovému systému než IP adresami a čísly portů. Cílem nové funkce je podporovat všechny funkce soketových kanálů domény Unix, které jsou společné napříč hlavními platformami Unix a Windows. Unixové doménové soketové kanály se budou chovat stejně jako stávající kanály TCP / IP, pokud jde o chování při čtení / zápisu, nastavení připojení, přijímání příchozích připojení servery a multiplexování s jinými neblokujícími volitelnými kanály ve voliči. Zásuvky domény Unix jsou bezpečnější a efektivnější než zpětné smyčky TCP / IP pro místní meziprocesovou komunikaci.
• Rozhraní API pro přístup do cizí paměti, které umožňuje programům Java bezpečně přistupovat k cizí paměti mimo haldu Java. Dříve inkubované v JDK 14 i JDK 15, API pro přístup do cizí paměti by bylo znovu inkubováno v JDK 16, přidáním vylepšení. Byly provedeny změny, včetně jasnějšího oddělení rolí mezi MemorySegment a Paměťové adresy rozhraní. Cíle tohoto návrhu zahrnují poskytnutí jediného rozhraní API pro provoz na různých druzích cizí paměti, včetně nativní, trvalé a spravované paměti haldy. API by nemělo podkopávat bezpečnost JVM. Motivací návrhu je, že mnoho programů Java přistupuje k cizí paměti, například Ignite, Memcached a MapDB. Rozhraní Java API však neposkytuje uspokojivé řešení pro přístup k cizí paměti.
• Přizpůsobení vzoru pro instanceof operátor, který byl také zobrazen v náhledu v JDK 14 i JDK 15. Dokončen by byl v JDK 16. Porovnávání vzorů umožňuje stručnější a bezpečnější vyjádření běžné logiky v programu, konkrétně podmíněné extrakce komponent z objektů.
• Poskytování nástroje jpackage pro balení samostatných aplikací Java. Představen jako inkubační nástroj v JDK 14, jpackage zůstal v inkubaci v JDK 15. S JDK 16 se jpackage přesouvá do výroby a podporuje nativní formáty balíčků, které uživatelům poskytnou přirozený zážitek z instalace a umožní specifikovat parametry doby spuštění v době balení. Formáty zahrnují msi a exe v systému Windows, pkg a dmg v systému MacOS a deb a rpm v systému Linux. Nástroj lze vyvolat přímo z příkazového řádku nebo programově. Nový balicí nástroj řeší situaci, ve které je třeba mnoho aplikací Java instalovat na nativní platformy prvotřídním způsobem, než aby byly umístěny na cestu třídy nebo cestu modulu. Je nutný instalovatelný balíček vhodný pro nativní platformu.
• Migrace úložišť zdrojového kódu OpenJDK z Mercurialu na Git. K tomuto úsilí přispívají výhody ve velikosti metadat systému řízení verzí a dostupných nástrojích a hostování.
• Migrace na GitHub, související s migrací Mercurial-to-Git, s úložištěmi zdrojových kódů JDK 16, které mají být na populárním webu pro sdílení kódu. Součástí tohoto plánu budou vydání funkcí JDK a vydání aktualizace JDK pro prostředí Java 11 a novější. Přechod na Git, GitHub a Skara pro Mercurial JDK a JDK-sandbox byl proveden 5. září a je otevřený pro příspěvky.

Předběžné verze JDK 16 pro Linux, Windows a MacOS najdete na jdk.java.net. Stejně jako JDK 15 bude i JDK 16 krátkodobým vydáním podporovaným po dobu šesti měsíců. JDK 17, který má vyjít v září 2021, bude vydáním dlouhodobé podpory (LTS), které bude mít několikaletou podporu. Aktuální vydání LTS, JDK 11, bylo vydáno v září 2018.