--- title: "Jak upgradovat kritickou aplikaci z Javy 8 na moderní Javu" description: "Praktický plán, jak převést kritickou aplikaci v Javě 8 na aktuální LTS verzi: inventura závislostí, upgrade po krocích, testy, úskalí a zátěžové testování." canonical: https://sdk.enterprises/cs/insights/upgrading-legacy-java language: cs --- # Jak upgradovat kritickou aplikaci z Javy 8 na moderní Javu Aktualizováno: 2026-09-25 > Kritickou aplikaci v Javě 8 upgradujte po etapách: zinventarizujte každou závislost, přejděte nejdřív na Javu 11 a pak na každou další verzi s dlouhodobou podporou (LTS) a o tom, kdy je který krok bezpečný, ať rozhodují testy a zátěžové testy. Většina práce leží v knihovnách, nástrojích pro sestavení a kódu, který sahá na vnitřnosti JDK, ne ve vaší obchodní logice. ## Setrvání na Javě 8 vám každý rok zužuje možnosti Aplikace v Javě 8 může běžet ještě roky, a v tom je past. Bezpečnostní opravy čím dál víc závisejí na placené smlouvě o podpoře nebo na distribuci, která je ještě zpětně portuje, a hlavní knihovny se posunuly dál. Například Spring Boot 3 vyžaduje minimálně Javu 17, takže setrvání na Javě 8 zmrazí i verze vašeho frameworku. Novější JVM navíc stejný kód spouštějí lépe. G1 je výchozím garbage collectorem od Javy 9, collectory s krátkými pauzami, jako je ZGC, jsou připravené pro produkci a kompaktní řetězce snižují spotřebu paměti u zátěží s velkým množstvím textu. Vývojáři také očekávají moderní jazykové prvky, jako jsou records, text blocks a switch výrazy, takže pro kódovou základnu v Javě 8 se hůř shánějí lidé. ## Začněte inventurou všeho, na čem aplikace závisí Samotný upgrade JDK bývá málokdy tou těžkou částí. Těžký je dlouhý chvost knihoven, pluginů a agentů, které byly napsány pro Javu 8 a nikdy se neaktualizovaly. Než cokoli změníte, sestavte úplný seznam a u každé položky zaznamenejte verzi. - Dodavatele a verzi JDK v každém prostředí, od notebooků vývojářů po produkci. - Přímé i tranzitivní závislosti, exportované ze stromu závislostí Mavenu nebo z reportu závislostí Gradlu. - Pluginy pro sestavení, generátory kódu a procesory anotací, jako je Lombok. - Aplikační server nebo servletový kontejner, pokud v něm aplikace běží. - Java agenty pro monitoring, profilování nebo bezpečnost, které se napojují hluboko do JVM. - Kód, který používá interní API JDK, nalezený nástrojem jdeps a jeho volbou jdk-internals. - Parametry JVM, nastavení garbage collectoru a všechny skripty, které parsují výstup java -version. ## Postupujte přes verze s dlouhodobou podporou, nepřeskakujte Přejděte z Javy 8 na 11, pak na 17 a pak na 21 nebo 25. Každý skok má vlastní sadu odstraněných částí a změn chování a jediný velký skok je všechny smíchá do jednoho selhání, které nedokážete diagnostikovat. Když opravujete jednu vrstvu po druhé, zůstává každý krok dost malý na revizi i na návrat zpět. Kde to jde, upgradujte knihovny ještě na Javě 8, protože mnoho novějších verzí podporuje staré i nové JDK. Pak spusťte stávající sestavení na novém JVM, než změníte cíl kompilace. Tím oddělíte problémy běhového prostředí od problémů kompilátoru a parametr kompilátoru release drží cílovou verzi bajtkódu explicitní. ## Sada testů ať je bránou pro každý krok Testy jsou jediným objektivním signálem, že se upgradovaná aplikace chová stále stejně. Pokud mají kritické cesty malé pokrytí, napište nejdřív charakterizační testy: testy, které zachytí, co systém dělá dnes, včetně jeho podivných hraničních případů, aniž by posuzovaly, zda je to chování správné. Přidejte integrační testy, které běží proti skutečné databázi a skutečným message brokerům, protože mnoho selhání upgradu se projeví až na těchto hranicích. U systémů s velkým množstvím výpočtů přehrajte stejné vstupy starou i novou verzí a výstupy porovnejte pole po poli. Dávejte pozor na data, čísla a text: Java 9 přešla na výchozí jazyková data CLDR a Java 18 udělala z UTF-8 výchozí znakovou sadu, a obojí může potichu změnit formátování nebo parsování. ## Znejte úskalí, na kterých kód z Javy 8 padá Většina rozbití spadá do několika známých kategorií. Každou z nich vyhledejte před upgradem, místo abyste ji objevili v produkci. - Odstraněné moduly Java EE a CORBA: Java 11 vyřadila z JDK JAXB, JAX-WS, JavaBeans Activation a společné anotace, takže je třeba je přidat zpět jako explicitní závislosti. - Silné zapouzdření vnitřností JDK: nepovolený reflexivní přístup vyvolával od Javy 9 varování, od Javy 16 je ve výchozím stavu zakázán a od Javy 17 ho nelze globálně znovu zapnout. Řešte to upgradem knihovny; add-opens používejte jen jako zdokumentovanou dočasnou výjimku. - Zastaralé nástroje pro práci s bajtkódem: starší verze Lomboku, Mockita, Byte Buddy, ASM a pluginů pro sestavení selhávají na novějších verzích class souborů. - Odstraněné funkce: javascriptový engine Nashorn byl odstraněn v Javě 15 a Security Manager byl v Javě 17 označen jako zastaralý a v Javě 24 trvale vypnut. - Odstraněné parametry JVM: garbage collector CMS byl odstraněn v Javě 14 a JVM spuštěný s odstraněnými volbami může odmítnout nastartovat. ## Výkon prokažte pod realistickou zátěží, ne na notebooku Nové JDK mění garbage collector, JIT kompilátor i rozložení paměti, takže výkon se může pohnout oběma směry. Před každým krokem i po něm spusťte zátěžový test, který reprodukuje profil produkčního provozu, na stejném hardwaru nebo typu instance. Porovnejte percentily latence, propustnost, paměť a pauzy garbage collectoru a před měřením nechte JIT zahřát. Naši inženýři přes Sopra Steria vedli migraci kritické aplikace pro denní obchodování s plynem z Javy 8 na 16 pro národní obchodní desk s plynem. V tomto systému musely výpočty kapacit a toků energie zůstat správné a rychlé i pod vysokofrekvenční zátěží, proto upgrade šel ruku v ruce s optimalizací těchto výpočtů a byl ověřen pod zátěží, ne jen předpokládán. ## Nasazujte postupně a nechte si cestu zpět Upgradované běhové prostředí nejdřív nasaďte na jednu instanci nebo na malý podíl provozu a sledujte chybovost, latenci a chování garbage collectoru ve srovnání s výchozím stavem na Javě 8. Předchozí sestavení udržujte nasaditelné, dokud nová verze neprojde běžnými obchodními cykly, včetně konce měsíce nebo období špiček. Teprve pak odstraňte artefakty pro Javu 8 a začněte používat nové jazykové prvky. Pokud chcete pomoc s plánováním nebo provedením takového upgradu, SDK Enterprises ho obsadí interními inženýry a prověřenými specialisty v rámci jedné smlouvy, za kterou odpovídá. ## Hlavní body - Práce při upgradu z Javy 8 leží hlavně v závislostech, nástrojích pro sestavení a používání vnitřností JDK, ne v obchodní logice. - Postupujte přes verze s dlouhodobou podporou jednu po druhé, aby každé selhání mělo jedinou dohledatelnou příčinu. - Charakterizační a integrační testy jsou bránou pro každý krok, zejména kolem dat, čísel a kódování textu. - Výkon ověřte pod zátěží podobnou produkci, protože změny garbage collectoru a JIT mohou výsledky posunout oběma směry. - Nejdřív nasaďte na malý podíl provozu a sestavení pro Javu 8 udržujte nasaditelné, dokud se nové běhové prostředí neosvědčí. ## Časté dotazy ### Můžu upgradovat přímo z Javy 8 na Javu 21? Můžete, ale zdědíte naráz všechny změny od Javy 9 do 21, takže se selhání těžko dohledávají. Postup přes 11 a 17 stojí o něco víc času na sestavení a u kritického systému ušetří spoustu ladění. ### Jak dlouho trvá upgrade z Javy 8? Záleží na počtu závislostí, na tom, kolik z nich používá vnitřnosti JDK, na pokrytí testy a na tom, kolik zátěžového testování systém potřebuje. Inventura a zkušební běh na novém JVM vám realistický odhad dají brzy, ještě než se zavážete k harmonogramu. ### Musím přepsat kód, abych mohl používat nové funkce Javy? Ne. Java drží silnou zpětnou kompatibilitu pro kód, který se drží standardních API, jež nejsou označená jako zastaralá. Records, text blocks a další prvky zavádějte postupně, až bude upgradované běhové prostředí v produkci stabilní. ## Související služby - [Software na míru](https://sdk.enterprises/cs/services/product-engineering) - [Bezpečnost aplikací](https://sdk.enterprises/cs/services/secure-systems)