Java 26: Rychlejší starty, bezpečnější kód a licence, které je čas revidovat

Verze 26 je ukázkovou evolucí zaměřenou na Developer Experience a Snížení TCO (Total Cost of Ownership). Přináší s sebou ale i technologické a licenční změny, které vyžadují, abychom k plánovanému upgradu přistoupili s rozmyslem – obzvlášť, pokud spravujete starší systémy.

Co by tedy z novinek nemělo uniknout vývojářům, a proč by u této aktualizace měl zpozornět i IT management?

Pro vývojáře: Méně boilerplate kódu a stabilní mikroslužby

Z pohledu softwarového inženýrství Java 26 elegantně odstraňuje historické tření. Místo nekritického naskakování na AI hype-train přináší funkce, které oceníte při každodenním nasazování do produkce.

• JEP 525: Structured Concurrency (Sixth Preview): Tohle je dlouho očekávaná odpověď na padající vlákna a „thread leaky“. Nativní a čistý způsob, jak strukturovat paralelní úlohy běžící v různých vláknech jako jednu logickou jednotku. Výsledek? Lepší kontrola nad paralelními úlohami a jednodušší error handling při volání více asynchronních API.
• JEP 517: HTTP/3 pro Client API: Komunikace s moderními servery s nižší latencí a vyšší spolehlivostí. Díky nativní podpoře v klientu umožňuje využít HTTP/3, což může v některých scénářích snížit latenci, pokud jej server podporuje.
• JEP 530: Primitive Types in Patterns, instanceof, and switch: Drobná, ale zásadní úleva. Konec nutnosti používat těžkopádná přetypování v pattern matchingu. Vaše switch konstrukce budou zas o něco čistší a bezpečnější, protože kompilátor ohlídá mnohem širší spektrum chyb už při buildu.

Zajímá vás moderní Java v praxi?
Baví vás posouvat výkon aplikací a chcete s námi nové technologie testovat v produkci? Mrkněte na naše volné pozice pro Java vývojáře.

Pro byznys a infrastrukturu: Rychlejší start a levnější provoz

Zatímco vývojáře zajímá čistota kódu, management a architekty zajímají náklady na provoz v cloudu (AWS, Azure, OCI). Zde Java 26 září nejvíce:

• JEP 516: Ahead-of-Time Object Caching (Project Leyden): Problém pomalého startu Java aplikací (tzv. cold-starts) a zahřívání JVM je dlouhodobým úskalím, zejména v serverless architektuře. JEP 516 zlepšuje start aplikací využitím cachovaných dat z předchozího běhu JVM. Reálný dopad? Znatelně rychlejší náběh aplikací a plynulejší škálování při zátěžových špičkách.
• JEP 522: G1 GC – Improve Throughput by Reducing Synchronization: Drobná úprava v Garbage Collectoru s velkým byznysovým dosahem. Bez jakékoliv změny ve vašem kódu dokáže aplikace díky efektivnější správě paměti a snížené synchronizaci mezi aplikací a GC vlákny může v některých případech zvýšit propustnost aplikace díky efektivnější správě paměti.

Technický háček: Konec hluboké reflexe (JEP 500)

Aktualizace na Java 26 však nebude jen o stisku tlačítka „Update“. Skrývá se v ní technický rozměr, který vyžaduje pozornost: JEP 500 (Prepare to Make Final Mean Final).

Java dlouhodobě staví na principu „integrity by default“. JEP 500 začne vydávat varování při pokusech o manipulaci s immutable (final) poli pomocí tzv. hluboké reflexe. Tento krok naznačuje, že v budoucích verzích může být taková činnost omezena nebo zakázána, pokud vývojář výslovně nepovolí výjimku. Z pohledu bezpečnosti je to skvělá zpráva, která ochrání vaši byznys logiku.

Z pohledu migrace je to ale výzva. Řada starších (legacy) verzí populárních frameworků, DI kontejnerů (Spring), ORM nástrojů (Hibernate) nebo testovacích knihoven na těchto skrytých reflexních drátováních doteď fungovala. Při přechodu na Java 26 mohou některé starší knihovny využívající hlubokou reflexi vyžadovat úpravy. Přechod může v závislosti na použitém stacku vyžadovat revizi nebo úpravy části kódu.

Nenápadná příprava na AI a vyčištění starých pořádků

Ačkoliv Java 26 nenese nálepku LTS (Long Term Support – tou byla předchozí Java 25) a konzervativnější enterprise týmy ji v produkci pravděpodobně přeskočí, přináší novinky, které formují budoucnost platformy. A to zejména v oblasti bezpečnosti a pragmatické integrace umělé inteligence:

• JEP 526: Lazy Constants (Second Preview): Tato novinka (dříve známá jako Stable Values) umožňuje inicializovat neměnná data až ve chvíli, kdy jsou skutečně potřeba. Výsledek? Stejný výkonnostní profil jako u klasických final proměnných, ale s obrovskou úsporou na začátku. To je užitečné zejména pro aplikace pracující s velkými objemy dat nebo rozsáhlou konfigurací, které potřebují nahrávat masivní jazykové modely či obří konfigurace, aniž by to drasticky zpomalilo start aplikace.
• Project Detroit: Na konferenci JavaOne byla odhalena iniciativa, která má umožnit volání Python a JavaScript runtimů přímo uvnitř JVM (in-process). Cíl je jasný: umožnit Java vývojářům nativně využívat masivní ekosystém AI knihoven z Pythonu, aniž by museli opouštět Javu nebo složitě spravovat oddělené procesy.
• JEP 524: PEM Encoding API: Pro týmy řešící cloudovou bezpečnost a compliance jde o skvělou zprávu. Nové API razantně zjednodušuje práci s kryptografickými klíči a certifikáty, čímž snižuje riziko chyb při zabezpečování mikroslužeb.
• JEP 504: Definitivní konec Appletů: Pro pamětníky – Java 26 finálně odstraňuje Applet API, které bylo „deprecated for removal“ už od verze 17. Definitivní sbohem technologii, kterou dnešní prohlížeče dávno nepodporují. Platforma je díky tomu opět o něco štíhlejší a bezpečnější.

Změny v licencích a ekosystému: Oracle utahuje pravidla

Aby toho nebylo málo, Oracle spolu s Java 26 představil balíček Oracle Java Verified Portfolio (JVP). Tento kurátorovaný set enterprise komponent přináší pod křídla Oracle například podporu populárního frameworku Helidon, nástroje pro VS Code a po letech vrací oficiální komerční podporu pro vizualizace v JavaFX.

Na první pohled skvělá zpráva o stabilizaci ekosystému. Realita je ale taková, že Oracle poskytuje podporu JVP zdarma a s plnou SLA pouze pro Java SE předplatitele a zákazníky Oracle Cloud Infrastructure (OCI). Mnoho komponent JVP sice zůstává volně přístupných i pro ostatní uživatele, ale v enterprise sféře se tak hranice mezi „free open-source“ a „komerčně licencovaným“ stává opět o něco mlhavější. Není tedy překvapením, že podle nezávislé analytické zprávy State of Java Report od Azul Systems v současnosti přes 81 % organizací aktivně řeší alternativní JDK distribuce. Důvodem není to, že by Oracle Java byla technologicky špatná – jde o pragmatickou optimalizaci nákladů a prevenci vendor lock-inu.

Krok nula: Než začnete migrovat

Zde do sebe výše popsané body zapadají. Pokud chcete využít výkonnostních výhod Javy 26, vaši vývojáři pravděpodobně budou muset strávit čas revizí a přepisováním části staršího kódu právě kvůli technickým blokům, jako je JEP 500.

Než ale na tento refaktoring začnete pálit drahý čas a kapacity vašich seniorních vývojářů, ujistěte se, že máte v pořádku infrastrukturu.

Přechod na novou verzi je ideální čas zjistit, na čem vaše produkční aplikace reálně stojí. Využíváte nevědomky komponenty, které spadají do placeného Oracle JVP? Hrozí vám zbytečné vícenáklady z neznalosti aktuálních licenčních modelů? A nevyplatí se vám vzhledem k vašemu stacku využít OpenJDK alternativy?

Nenechte se při migraci nebo Oracle auditu zaskočit. Náš Java Licence Assessment Service slouží přesně jako tento „krok nula“ před každým hlubokým zásahem do produkce. Pomůžeme vám zmapovat celkové náklady na vlastnictví (TCO) vašich Java projektů, odhalíme skrytá licenční rizika a navrhneme optimální a bezpečnou cestu k využití moderních technologií – ať už pro klidný spánek managementu, nebo čistší práci vašich vývojářů.

Z celkového počtu 36 328 úkolů v systému JIRA, které byly v době vydání verzí Java 11 až Java 26 označeny jako vyřešené, jich 25 491 dokončili zaměstnanci společnosti Oracle, zatímco 10 837 jich přispěli individuální vývojáři a vývojáři pracující pro jiné organizace.

V Javě 26 bylo z 2 535 úkolů v systému JIRA označených jako vyřešené celkem 1 729 dokončeno společností Oracle, zatímco 806 jich přispěli ostatní členové komunity Java.

Zdroj informací: Oracle, TheNewStack