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í.