Verze Long-Term-Support (LTS) jazyka Java a runtime platformy Java 17 byla spuštěna 14. září 2021. Pojďme se dozvědět, co je nového v Java 17 a zda byste měli upgradovat.
Mnoho aplikací používá starší verze Javy, včetně dřívějších LTS verzí Javy: Java 11 a Java 8.
Proč by podniky měly upgradovat na nejnovější verzi Java? Upgrade na Java 17 vyžaduje úsilí, hlavně aby bylo možné co nejlépe využít nové vlastnosti a funkce uvnitř JVM.
Mnoho podniků používá obrázky Docker a Docker ke snadnému přechodu na Java 17 s minimálním úsilím a časem. Vývojáři mohou definovat své kanály průběžné integrace/deploymentu (CI/CD) a vše spouštět v obrazech Docker. To neovlivní ostatní týmy používající starší verze Java, protože mohou využívat staré obrazy Dockeru.
Table of Contents
Funkce JAVA 17
Podpora macOS a AArch64
Jednou z kritických funkcí JVM přidaných do této verze je vylepšení podpory pro macOS na architektuře AArch64 pomocí JEP 391. Bude podporovat nejnovější řadu procesorů (M1), které Apple vydal se svými počítači v minulém roce.
Pro uživatele na těchto platformách to nemusí být nutně velký problém, protože někteří dodavatelé spustili verze JDK, které tuto architekturu podporují, a dokonce vracejí podporu z Java 8. Oficiální pečeť schválení je však nezbytná pro zajištění budoucí údržby a podpory nástupiště. Pro srovnání, podpora platformy Linux/AArch64 byla přidána do Javy 9 a Windows/AArch64 v Javě 16.
Uzavřené třídy
Zapečetěné třídy je funkce, která byla představena v Javě 17. Funkce zapečetěných tříd dokončila zkušební fázi a stala se oficiální platformou a jazykem v Javě 17. Umožňuje vývojářům specifikovat přípustné podtypy, které typ může mít a zabránit ostatním v jeho rozšiřování nebo implementaci způsobem, který není zamýšlen.
Zapečetěné třídy také umožňují kompilátoru generovat chyby v době kompilace, když se pokusíte převést nezapečetěný typ na nepovolený podtyp. Java 17 také přináší nový renderovací kanál pro aplikace AWT/Swing, které běží na macOS pomocí Apple Metal API místo OpenGL. Má vylepšené API a vylepšené funkce pro generování náhodných čísel.
Změny, mazání a omezení v Javě 17
Java 17 také přináší několik změn, odstranění a nová omezení.
Zapouzdření vnitřních částí JDK
Jednou změnou je uzavření procesu zapouzdření společnosti JDK Internals. Poprvé to bylo představeno v Javě 9 a během běhu zobrazovalo varování, když se uživatel pokusil použít reflexi nebo podobné, aby obešel obvyklá omezení používání interních API. K regulaci tohoto chování byly přidány také argumenty příkazového řádku.
Od Java 9 byla vytvořena různá API, která nabízejí jednotný způsob provádění nejběžněji používaných úloh; uživatelé by tato rozhraní API interně využívali. S Java 16 se výchozí nastavení změnilo z varování na zakázání přístupu k vyvolání výjimky. Ke změně chování však používá argument příkazového řádku.
S Java 17 je argument příkazového řádku eliminován a je možné toto omezení deaktivovat. To znamená, že veškerý neoprávněný přístup k těmto interním rozhraním API je nyní chráněn.
Vždy přísná sémantika s plovoucí desetinnou čárkou
Další „odstranění“ lze popsat jako znovuzavedení sémantiky Always-Strict s plovoucí desetinnou čárkou. Java 1.2 zavedla modifikace výchozí sémantiky s plovoucí desetinnou čárkou v Javě, což umožňuje JVM obchodovat s nepatrným množstvím přesnosti ve výpočtech s plovoucí desetinnou čárkou za účelem zlepšení výkonu. Ve třídách a metodách, kde musela být použita přísná sémantika, bylo přidáno klíčové slovo strictfp. Od té doby byly do CPU zavedeny různé typy instrukčních sad, díky nimž lze bez zbytečných nákladů používat přísnou sémantiku s pohyblivou řádovou čárkou. Potřeba implementovat výchozí nebo přísnou sémantiku byla odstraněna.
Java 17 odstraňuje předchozí výchozí sémantiku a všechny operace s pohyblivou řádovou čárkou jsou prováděny přísně. Termín strictfpis je stále přítomen. Nemá to však žádný účinek a způsobí varování v době kompilace.
Předběžná kompilace (AOT).
Java 9 představila předčasnou kompilaci (AOT) jako experimentální funkci, která využívá kompilátor Graal, a kód JIT byl napsán pomocí Javy. Java 10 učinila kompilátor Graal použitelný jako kompilátor JIT v OpenJDK začleněním rozhraní JVMCI. Od té doby, co byla vydána, došlo k obrovskému zlepšení. Kompilátor Graal zaznamenal obrovský pokrok a má své JVM pod názvem GraalVM.
Aktivace RMI
Aktivace RMI byla eliminována v JEP 407 po jeho odstranění z Java 8 a nakonec zavrženo a označeno jako požadavek na odstranění v rámci Java 15. Aktivace RMI poskytla metodu umožňující distribuované objekty na vyžádání pomocí RMI. Byl však minimálně využíván a v současnosti je k dispozici lepší alternativa. Zbytek RMI není ovlivněn eliminací aktivační části.
Odstranění applet API
Applet API bylo konečně určeno k odstranění JEP 398, původně odstraněno v rámci Java 9. Applet API poskytlo způsob, jak integrovat ovládací prvky Java AWT/Swing do webové stránky v prohlížeči. To však žádný moderní prohlížeč nepodporuje, což znamená, že aplety byly v posledních zhruba deseti letech v podstatě nepřístupné.
Bezpečnostní manažer
Nejzásadnějším zrušením podpory je správce zabezpečení ( JEP 411). Security Manager se nějakou dobu používá od Java 1.0. Byl navržen tak, aby omezoval to, co může Java dělat lokálně na počítači, jako je omezení přístupu k sítím, souborům a dalším síťovým zdrojům. Také se pokouší vložit kód do karantény, který není důvěryhodný, tím, že zablokuje odraz a konkrétní API.
Konec Security Manager začal v Javě 12. Byl přidán argument příkazového řádku, který blokuje použití správce zabezpečení za běhu. Změna provedená v Javě 17 znamená, že při pokusu o nastavení Security Manager bude v JVM generováno runtime varování, a to buď z příkazového řádku, nebo dynamicky za běhu.
Funkce inkubátoru a náhledu
Mnozí se ptali, zda bude mít Java 17 nějaké funkce náhledu a inkubátoru, vzhledem k tomu, že Java 17 byla povýšena na dlouhodobě podporovanou verzi. Java 17 má dva moduly inkubátoru a funkci náhledu!
Vektorové API
Vektorové API ( JEP 414) je v současné době ve své druhé fázi inkubátoru. Rozhraní API umožňuje vývojářům definovat vektorový výpočet, který kompilátor JIT poté převede na příslušnou vektorovou instrukci podporovanou architekturou CPU, na které běží JVM (například pomocí instrukcí ze sad SSE nebo AVX).
Dříve museli vývojáři používat skalární funkce nebo vytvářet nativní knihovny, které byly specifické pro platformu. Implementace Vector API v Javě také poskytuje bezproblémový záložní mechanismus, který byl v dřívějších verzích komplikovaný.
Standardizace Vector API umožňuje třídám v rámci JDK je používat. Metody Java Arrays mismatch() by mohly být změněny tak, aby byly spouštěny v Javě, čímž se eliminuje požadavek na údržbu a psaní implementací pro různé platformy v rámci JVM.
Rozhraní API pro cizí funkce a paměť
Další funkce inkubátoru se nazývá Foreign Function & Memory API ( JEP 412). Jedná se o evoluci a sloučení dvou dalších modulů inkubátoru Java 16, což je The Foreign Linker API ( JEP 389) a Foreign-Memory API ( JEP 393). Oba poskytují přístup k nativní paměti a kódu pomocí staticky typovaného programování napsaného v Javě.
Přizpůsobení vzoru pro přepínač
Poslední funkcí jazykového náhledu zahrnutého v Javě 17 je zahrnutí Pattern Matching pro Switch ( JEP 406). Tato jazyková funkce rozšiřuje výrazy a příkazy přepínače podle typu, podobně jako syntaxe používaná prostřednictvím porovnávání vzorů (JEP 394), který se stal standardem s Java 16.
Pokud jste v minulosti chtěli provádět různé akce na základě dynamické povahy objektu, museli jste vytvořit řetězec if-else pomocí instance kontrol, jako jsou:
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.";
}
}
Kombinací výrazu přepínače a nové funkce porovnávání vzorů pro přepínače lze proces zredukovat na něco podobného:
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.";
};
}
Jak jste si možná všimli, v procesu kontroly je deklarace proměnné. Stejně jako ostatní proměnné ve vzoru, shoda instance indikuje, že tento objekt byl typově zkontrolován a přetypován a je dostupný z proměnné v jeho aktuální oblasti.
Funkce náhledu je dalším krokem k porovnávání vzorů. Dalším krokem je zahrnutí schopnosti dekonstrukce polí a záznamů.
Měli byste upgradovat na Java 17?
Ano, musíte neustále upgradovat na nejnovější verzi, ale ne hned od prvního dne. Software a knihovny, které používáte, možná nebyly aktualizovány, aby zahrnovaly kompatibilitu s Java 17, takže možná budete muset nějakou dobu počkat, než to bude hotové.
Pokud jste uvízli u LTS verze Javy, jako je Java 8 nebo Java 11, existuje mnoho možností v rámci jazyka a v rámci samotného JVM, které vyžadují upgrade na Javu 17. Vzhledem k tomu, že se jedná o dlouhodobou verzi údržby, vysoká šance, že vaše produkční prostředí bude nakonec také aktualizováno na Java 17.
Pokud začínáte se zcela novým projektem nebo jste v procesu přípravy projektu na Java 17, je pravděpodobně nejefektivnější volbou provést přechod na Java 17 dříve než později, protože snižuje náklady na přesun. To také umožňuje vývojářům pracujícím na projektu využívat všechny nejnovější funkce a operační stránku.
Můžete využít mnoha vylepšení, ke kterým došlo během několika posledních let, jako je vylepšená podpora kontejnerů běžících na Javě a také nové implementace garbage collectoru s nízkou latencí.