Sdílet prostřednictvím

Přechod z Javy 8 na Javu 11

Neexistuje žádné univerzální řešení pro přechod kódu z Javy 8 na Javu 11. Přechod z Javy 8 na Javu 11 může být pro ne triviální aplikaci značným množstvím práce. Mezi potenciální problémy patří odebrané rozhraní API, zastaralé balíčky, použití interního rozhraní API, změny zavaděčů tříd a změny uvolňování paměti.

Obecně platí, že se jedná o pokus o spuštění v Javě 11 bez opětovného kompilace nebo kompilace pomocí sady JDK 11. Pokud je cílem co nejrychleji zprovoznění aplikace, je často nejlepším přístupem jen pokus o spuštění v Javě 11. Cílem knihovny bude publikovat artefakt, který je zkompilovaný a otestovaný pomocí sady JDK 11.

Přechod na Javu 11 stojí za to. Od Verze Java 8 byly přidány nové funkce a vylepšení. Tyto funkce a vylepšení zlepšují spouštění, výkon, využití paměti a poskytují lepší integraci s kontejnery. A existují doplňky a úpravy rozhraní API, které zlepšují produktivitu vývojářů.

Tento dokument se týká nástrojů pro kontrolu kódu. Řeší také problémy, na které můžete narazit a doporučení k jejich řešení. Měli byste se také obrátit na další příručky, jako je průvodce migrací Oracle JDK. Jak vytvořit stávající modulární kód, zde není popsaný.

Sada nástrojů

Java 11 má dva nástroje, jdeprscan a jdeps, které jsou užitečné pro šifrování potenciálních problémů. Tyto nástroje je možné spouštět na existujících třídových nebo JAR souborech. Přechodové úsilí můžete vyhodnotit bez nutnosti rekompilovat.

jdeprscan hledá použití zastaralého nebo odebraného API. Použití zastaralého rozhraní API není blokující problém, ale je to něco, co je potřeba prozkoumat. Existuje aktualizovaný soubor JAR? Potřebujete nahlásit problém s použitím zastaralého rozhraní API? Použití odebraného rozhraní API je blokující problém, který je potřeba vyřešit před pokusem o spuštění v Javě 11.

jdeps, což je analyzátor závislostí třídy Java. Při použití možnosti --jdk-internals, vám jdeps řekne, která třída závisí na kterém interním rozhraní API. V Javě 11 můžete dál používat interní rozhraní API, ale nahrazení využití by mělo mít prioritu. Wiki stránka OpenJDK, Java Dependency Analysis Tool, doporučuje náhrady některých běžně používaných interních rozhraní API JDK.

Pro Gradle i Maven existují moduly plug-in jdeps a jdeprscan . Tyto nástroje doporučujeme přidat do skriptů sestavení.

Nástroj Plug-in Gradle Plug-in Maven
jdeps jdeps-gradle-plugin Plugin Apache Maven JDeps
jdeprscan jdeprscan-gradle-plugin Plugin Apache Maven JDeprScan

Samotný kompilátor Java javac je dalším nástrojem v sadě nástrojů. Upozornění a chyby z nástrojů jdeprscan a jdeps budou vycházet z kompilátoru. Výhodou použití souboru jdeprscan a jdeps je, že tyto nástroje můžete spouštět přes existující soubory JAR a soubory tříd, včetně knihoven třetích stran.

Co jdeprscan a jdeps nemůže udělat, je varovat o použití reflexe pro přístup k zapouzdřenému rozhraní API. Reflexní přístup je kontrolován během spuštění. Nakonec musíte kód spustit na Javě 11, abyste měli jistotu.

Použití nástroje jdeprscan

Nejjednodušší způsob, jak použít jdeprscan , je dát mu soubor JAR z existujícího sestavení. Můžete mu také dát adresář, například výstupní adresář kompilátoru nebo název jednotlivé třídy. --release 11 Pomocí této možnosti získáte kompletní seznam zastaralého rozhraní API. Pokud chcete určit prioritu, na které zastaralé rozhraní API se zaměřit, vraťte nastavení zpět na --release 8. Rozhraní API, které bylo v Javě 8 zastaralé, se pravděpodobně odebere dříve než rozhraní API, které bylo vyřazeno v poslední době.

jdeprscan --release 11 my-application.jar

Nástroj jdeprscan vygeneruje chybovou zprávu, pokud má potíže s řešením závislé třídy. Například: error: cannot find class org/apache/logging/log4j/Logger. Přidání závislých tříd do --class-path nebo použití cesty třídy aplikace se doporučuje, ale nástroj bude pokračovat ve skenování bez ní. Argumentem je --class-path. Žádné jiné varianty argumentu třídy cesty nebudou fungovat.

jdeprscan --release 11 --class-path log4j-api-2.13.0.jar my-application.jar
error: cannot find class sun/misc/BASE64Encoder
class com/company/Util uses deprecated method java/lang/Double::<init>(D)V

Tento výstup nám říká, že com.company.Util třída volá zastaralý konstruktor java.lang.Double třídy. Javadoc doporučí rozhraní API pro použití místo zastaralého rozhraní API. Žádné množství práce nevyřeší problém, protože se jedná o rozhraní API, které bylo odebráno. Od verze Java 8 by se mělo používat java.util.Base64.

Spusťte jdeprscan --release 11 --list , abyste získali představu o tom, jaké rozhraní API bylo od Javy 8 zastaralé. Pokud chcete získat seznam odebraných rozhraní API, spusťte jdeprscan --release 11 --list --for-removalpříkaz .

Použití jdeps

Pomocí příkazu jdeps s --jdk-internals možností najít závislosti na interním rozhraní API sady JDK. V tomto příkladu je potřeba použít možnost --multi-release 11 příkazového řádku, protože log4j-core-2.13.0.jar je soubor JAR s více verzemi. Bez této možnosti jdeps bude hlásit chybu, pokud najde soubor JAR s více vydáními. Možnost určuje, která verze souborů tříd se má zkontrolovat.

jdeps --jdk-internals --multi-release 11 --class-path log4j-core-2.13.0.jar my-application.jar
Util.class -> JDK removed internal API
Util.class -> jdk.base
Util.class -> jdk.unsupported
   com.company.Util        -> sun.misc.BASE64Encoder        JDK internal API (JDK removed internal API)
   com.company.Util        -> sun.misc.Unsafe               JDK internal API (jdk.unsupported)
   com.company.Util        -> sun.nio.ch.Util               JDK internal API (java.base)

Warning: JDK internal APIs are unsupported and private to JDK implementation that are
subject to be removed or changed incompatibly and could break your application.
Please modify your code to eliminate dependence on any JDK internal APIs.
For the most recent update on JDK internal API replacements, please check:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

JDK Internal API                         Suggested Replacement
----------------                         ---------------------
sun.misc.BASE64Encoder                   Use java.util.Base64 @since 1.8
sun.misc.Unsafe                          See http://openjdk.java.net/jeps/260

Výstup poskytuje dobré rady k odstranění použití interního rozhraní API sady JDK! Pokud je to možné, navrhuje se náhradní rozhraní API. Název modulu, ve kterém je balíček zapouzdřen, je uveden v závorkách. Název modulu lze použít s --add-exports nebo --add-opens pokud je nutné explicitně přerušit zapouzdření.

Použití sun.misc.BASE64Encoder nebo sun.misc.BASE64Decoder bude mít za následek java.lang.NoClassDefFoundError v Javě 11. Kód, který používá tato rozhraní API, musí být upraven tak, aby používal java.util.Base64.

Pokuste se eliminovat použití jakéhokoli rozhraní API pocházejícího z modulu jdk.unsupported. Rozhraní API z tohoto modulu bude odkazovat na JDK Enhancement Proposal (JEP) 260 jako navrhovanou náhradu. Ve zkratce, JEP 260 říká, že použití interního rozhraní API bude podporováno, dokud nebude k dispozici náhradní rozhraní API. I když váš kód může používat interní rozhraní API sady JDK, bude se i nadále spouštět aspoň na chvíli. Podívejte se na JEP 260, protože ukazuje na nahrazení některých interních rozhraní API. Obslužné rutiny proměnných lze použít například místo některého rozhraní SUN.misc.Unsafe API.

jdeps umí víc než jen prohledávat použití interních prvků JDK. Je to užitečný nástroj pro analýzu závislostí a generování souborů s informacemi o modulu. Další informace najdete v dokumentaci .

Použití javac

Kompilace pomocí sady JDK 11 bude vyžadovat aktualizace skriptů, nástrojů, testovacích architektur a zahrnutých knihoven. -Xlint:unchecked Pomocí možnosti javac získáte podrobnosti o použití interního rozhraní API sady JDK a dalších upozornění. Může být také nutné použít --add-opens nebo --add-reads zveřejnit zapouzdřené balíčky kompilátoru (viz JEP 261).

Knihovny můžou zvážit balení jako soubor JAR s více verzemi. Soubory JAR s více verzemi umožňují podporovat moduly runtime Java 8 i Java 11 ze stejného souboru JAR. Přidávají složitost do sestavení. Vytváření souborů JAR s více verzemi je nad rámec tohoto dokumentu.

Běží na Java 11

Většina aplikací by měla běžet v Javě 11 bez úprav. První věcí, kterou je potřeba zkusit, je spustit v Javě 11 bez rekompilování kódu. Smyslem pouze spuštění je zjistit, jaká upozornění a chyby vycházejí z provádění. Tento přístup získá
aplikace, která se bude spouštět v Javě 11 rychleji, tím, že se zaměří na minimum, které je potřeba provést.

Většinu problémů, se kterými se můžete setkat, je možné vyřešit bez nutnosti rekompilovat kód. Pokud je v kódu potřeba opravit problém, proveďte opravu, ale pokračujte v kompilaci pomocí sady JDK 8. Pokud je to možné, před kompilací pomocí sady JDK 11 pokračujte v tom, jak aplikaci java s verzí 11.

Kontrola možností příkazového řádku

Před spuštěním v Javě 11 proveďte rychlou kontrolu možností příkazového řádku. Odebrané možnosti způsobí ukončení virtuálního počítače Java Virtual Machine (JVM). Tato kontrola je obzvláště důležitá, pokud používáte možnosti protokolování GC, protože se výrazně změnily z Javy 8. Nástroj JaCoLine je vhodný k detekci problémů s možnostmi příkazového řádku.

Kontrola knihoven třetích stran

Potenciálním zdrojem potíží jsou knihovny třetích stran, které neřídíte. Knihovny třetích stran můžete proaktivně aktualizovat na novější verze. Nebo můžete zjistit, jaké výsledky přinese spuštění aplikace, a aktualizovat pouze ty knihovny, které jsou nezbytné. Problém s aktualizací všech knihoven na novou verzi je, že to ztěžuje nalezení hlavní příčiny, pokud dojde k nějaké chybě v aplikaci. Došlo k chybě kvůli nějaké aktualizované knihovně? Nebo došlo k chybě způsobené nějakou změnou modulu runtime? Problém s aktualizací pouze toho, co je potřeba, spočívá v tom, že řešení může trvat několik iterací.

Doporučujeme provést co nejméně změn a aktualizovat knihovny třetích stran jako samostatné úsilí. Pokud aktualizujete knihovnu třetí strany, častěji než ne, budete chtít nejnovější a nejlepší verzi, která je kompatibilní s Javou 11. V závislosti na tom, jak daleko je vaše aktuální verze, můžete chtít postupovat opatrněji a upgradovat na první verzi kompatibilní s Javou 9 nebo novější.

Kromě prohlížení poznámek k verzi můžete soubor JAR vyhodnotit pomocí nástrojů jdeps a jdeprscan. Skupina pro zvýšení kvality OpenJDK také udržuje stránku wikiwebu Pro zvýšení kvality , která uvádí stav testování mnoha projektů FOSS (Free Open Source Software) ve verzích OpenJDK.

Explicitně nastavit uvolňování paměti

Paralelní uvolňování paměti (Parallel GC) je výchozí uvolňování paměti v Javě 8. Pokud aplikace používá výchozí nastavení, měl by být GC explicitně nastaven pomocí možnosti příkazového řádku -XX:+UseParallelGC. Výchozí nastavení bylo v Javě 9 změněno na garbage collector Garbage First (G1GC). Aby bylo možné provést spravedlivé porovnání aplikace spuštěné v Javě 8 a Javě 11, musí být nastavení GC stejné. Experimentování s nastavením GC by mělo být odloženo, dokud se aplikace neověří na Javě 11.

Explicitní nastavení výchozích možností

Pokud běží na virtuálním počítači HotSpot, nastavení možnosti -XX:+PrintCommandLineFlags příkazového řádku vypíše hodnoty možností nastavených virtuálním počítačem, zejména výchozí hodnoty nastavené GC. Spusťte s tímto příznakem v Javě 8 a při spuštění v Javě 11 použijte vytištěné možnosti. Ve většině případů je výchozí nastavení stejné od 8 do 11. Použití nastavení z 8 ale zajišťuje paritu.

Doporučujeme nastavit možnost --illegal-access=warn příkazového řádku. V Javě 11 bude použití reflexe pro přístup k internímu rozhraní API sady JDK vést k neplatnému upozornění na reflexní přístup. Ve výchozím nastavení se upozornění vydává pouze pro první neplatný přístup. Nastavení --illegal-access=warn způsobí upozornění na každý nelegální reflexivní přístup. Najdete více případů nelegálního přístupu, pokud je možnost nastavena na upozornění. Dostanete ale také spoustu nadbytečných upozornění.
Jakmile aplikace běží na Javě 11, nastavte --illegal-access=deny, aby napodobilo budoucí chování běhového prostředí Javy. Počínaje Javou 16 bude výchozí hodnota --illegal-access=deny.

Varování ClassLoader

V Javě 8 můžete přetypovat zavaděč tříd systému na URLClassLoader. To obvykle provádí aplikace a knihovny, které chtějí vkládat třídy do třídní cesty za běhu. Hierarchie zavaděče tříd se změnila v Java 11. Zavaděč systémových tříd (označovaný také jako zavaděč tříd aplikace) je teď interní třídou. Přetypování na URLClassLoader za běhu vyvolá ClassCastException. Java 11 nemá API k dynamickému rozšíření cesty ke třídám za běhu, je však možné to provést pomocí reflexe, s očividnými upozorněními na používání interního API.

V Javě 11 zavaděč třídy spouštění načítá pouze základní moduly. Pokud vytvoříte zavaděč tříd s nadřazenou hodnotou null, nemusí najít všechny třídy platformy. V Javě 11 musíte v takových případech předat ClassLoader.getPlatformClassLoader() místo null jako zavaděč nadřazené třídy.

Změny dat národního prostředí

Výchozí zdroj pro data o lokalizaci v Javě 11 byl změněn pomocí JEP 252 na Společné úložiště dat o lokalizaci konsorcia Unicode. To může mít vliv na lokalizované formátování. Nastavte systémovou vlastnost java.locale.providers=COMPAT,SPI tak, aby se v případě potřeby vrátila k chování národního prostředí Java 8.

Potenciální problémy

Tady jsou některé běžné problémy, se kterým se můžete setkat. Sledujte odkazy pro více podrobností o těchto problémech.

Nerozpoznané možnosti

Pokud byla odebrána možnost příkazového řádku, aplikace vytiskne Unrecognized option: nebo Unrecognized VM option následované názvem chybné možnosti. Nerozpoznaná možnost způsobí ukončení virtuálního počítače. Možnosti, které jsou zastaralé, ale nebyly odstraněny, způsobí zobrazení upozornění VM.

Obecně platí, že možnosti, které byly odebrány, nemají žádnou náhradu a jediným možností je odebrat možnost z příkazového řádku. Výjimkou jsou možnosti protokolování pro garbage collection. Protokolování GC bylo znovu zkompilováno v Javě 9, aby používalo sjednocenou architekturu protokolování JVM. Viz "Tabulka 2-2 Mapování starších příznaků protokolování uvolňování paměti na konfiguraci Xlogu" v části Povolení protokolování pomocí sjednoceného protokolování JVM referenční příručky nástrojů Java SE 11.

Upozornění virtuálních počítačů

Použití zastaralých možností způsobí upozornění. Možnost je zastaralá, když byla nahrazena nebo už není užitečná. Stejně jako u odebraných možností by se tyto možnosti měly z příkazového řádku odebrat. Upozornění VM Warning: Option <option> was deprecated znamená, že je tato možnost stále podporovaná, ale tato podpora se může v budoucnu odebrat. Možnost, která již není podporována a vygeneruje upozornění VM Warning: Ignoring option. Možnosti, které už nejsou podporovány, nemají na modul runtime žádný vliv.

Webová stránka Průzkumník možností VM poskytuje úplný seznam možností, které byly od verze JDK 7 přidány do Javy nebo z ní odstraněny.

Chyba: Nepodařilo se vytvořit virtuální počítač Java

Tato chybová zpráva se vytiskne, když JVM narazí na nerozpoznanou možnost.

UPOZORNĚNÍ: Došlo k neoprávněné reflexivní operaci přístupu

Pokud kód Java používá reflexi pro přístup k internímu rozhraní API sady JDK, modul runtime vydá neplatné upozornění na reflexní přístup.

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by my.sample.Main (file:/C:/sample/) to method sun.nio.ch.Util.getTemporaryDirectBuffer(int)
WARNING: Please consider reporting this to the maintainers of com.company.Main
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

To znamená, že modul neexportoval balíček, ke kterému se přistupuje prostřednictvím reflexe. Balíček je zapouzdřen v modulu a je v podstatě interní rozhraní API. Upozornění lze ignorovat jako první krok k tomu, jak začít pracovat s Javou 11. Modul runtime Java 11 umožňuje reflexní přístup, aby starší kód mohl dál fungovat.

Pokud chcete toto upozornění vyřešit, vyhledejte aktualizovaný kód, který nepoužívá interní rozhraní API. Pokud problém nelze vyřešit aktualizovaným kódem, lze použít buď možnost příkazového řádku --add-exports, nebo --add-opens k otevření přístupu k balíčku. Tyto možnosti umožňují přístup k nevyexportovaným typům jednoho modulu z jiného modulu.

Tato --add-exports možnost umožňuje cílovému modulu přístup k veřejným typům pojmenovaného balíčku zdrojového modulu. Kód někdy použije setAccessible(true) pro přístup k neveřejným členům a rozhraní API. To se označuje jako hloubková reflexe. V tomto případě použijte --add-opens, abyste umožnili svému kódu přístup k neveřejným členům balíčku. Pokud si nejste jistí, jestli chcete použít --add-exports nebo --add-opens, začněte s --add-exports.

Tyto --add-exports možnosti --add-opens by se měly považovat za alternativní řešení, nikoli dlouhodobé řešení. Použití těchto možností narušuje zapouzdření systému modulů, který je určen k tomu, aby se interní rozhraní API sady JDK nepoužívalo. Pokud se interní rozhraní API odebere nebo změní, aplikace selže. Reflexní přístup bude v Javě 16 odepřen, s výjimkou případů, kdy je přístup povolený možnostmi příkazového řádku, jako --add-opensje . Pokud chcete napodobit budoucí chování, nastavte --illegal-access=deny ho na příkazovém řádku.

Upozornění ve výše uvedeném příkladu je vydáno, protože sun.nio.ch modul neexportuje java.base balíček. Jinými slovy, v exports sun.nio.ch; souboru modulu module-info.javanení žádný java.base . To lze vyřešit pomocí --add-exports=java.base/sun.nio.ch=ALL-UNNAMED. Třídy, které nejsou definovány v modulu implicitně patří do nepojmenovaného modulu, doslova pojmenovaného ALL-UNNAMED.

java.lang.reflect.InaccessibleObjectException

Tato výjimka označuje, že se pokoušíte volat setAccessible(true) na pole nebo metodu zapouzdřené třídy. Může se také zobrazit upozornění na nelegální přístup prostřednictvím reflexe. Pomocí možnosti --add-opens dejte svému kódu přístup k neveřejným členům balíčku. Zpráva o výjimce vám řekne, že modul "neotevře" balíček modulu, který se pokouší volat setAccessible. Pokud je modul "nepojmenovaný modul", použijte UNNAMED-MODULE ho jako cílový modul v možnosti --add-opens .

java.lang.reflect.InaccessibleObjectException: Unable to make field private final java.util.ArrayList jdk.internal.loader.URLClassPath.loaders accessible: 
module java.base does not "opens jdk.internal.loader" to unnamed module @6442b0a6

$ java --add-opens=java.base/jdk.internal.loader=UNNAMED-MODULE example.Main

java.lang.NoClassDefFoundError

NoClassDefFoundError je pravděpodobně způsobena rozděleným balíčkem nebo odkazem na odebrané moduly.

NoClassDefFoundError způsobená rozdělením balíčků

Dělený balíček je situace, kdy je balíček nalezen ve více než jedné knihovně. Příznak problému s rozdělením balíčku nastává, když není nalezena třída, která je známá být na class-path.

K tomuto problému dojde pouze při použití cesty modulu. Systém modulu Java optimalizuje vyhledávání tříd omezením balíčku na jeden pojmenovaný modul. Modul runtime dává přednost cestě modulu nad cestou třídy při vyhledávání třídy. Pokud je balíček rozdělený mezi modul a cestu třídy, použije se k vyhledání třídy pouze modul. To může vést k chybám NoClassDefFound .

Jednoduchým způsobem, jak zkontrolovat rozdělený balíček, je připojit cestu modulu a cestu ke třídám do jdeps a použít cestu k souborům tříd vaší aplikace jako cestu<. Pokud existuje rozdělený balíček, jeps vytiskne upozornění: Warning: split package: <package-name> <module-path> <split-path>.

Tento problém lze vyřešit přidáním --patch-module <module-name>=<path>[,<path>] rozděleného balíčku do pojmenovaného modulu.

NoClassDefFoundError způsobená použitím modulů Java EE nebo CORBA

Pokud aplikace běží na Javě 8, ale vyvolá java.lang.NoClassDefFoundError nebo a java.lang.ClassNotFoundException, je pravděpodobné, že aplikace používá balíček z modulů Java EE nebo CORBA. Tyto moduly byly vyřazeny v Javě 9 a odebrány v Javě 11.

Pokud chcete tento problém vyřešit, přidejte do projektu závislost modulu runtime.

Odebraný modul Ovlivněný balíček Navrhovaná závislost
Rozhraní Java API pro webové služby XML (JAX-WS) java.xml.ws JAX WS RI Runtime
Architektura Java pro vazbu XML (JAXB) java.xml.bind JAXB Runtime
JavaBeans Activation Framework (JAV) java.activation Architektura aktivace JavaBeans (TM)
Běžné poznámky java.xml.ws.annotation Rozhraní API pro poznámky Javax
Architektura společného zprostředkovatele požadavků objektů (CORBA) java.corba GlassFish CORBA ORB
Java Transaction API (JTA) java.transaction Rozhraní API pro transakce Java

-Xbootclasspath/p už není podporovaná možnost.

Podpora pro -Xbootclasspath/p byla odebrána. Místo toho použijte --patch-module. Možnost --patch-module je popsaná v JEP 261. Vyhledejte část s popiskem "Obsah modulu oprav". --patch-module lze použít s javac a s java pro přepsání nebo rozšíření tříd v modulu.

Co --patch-module vlastně dělá, je vložit opravný modul do systému vyhledávání tříd v modulu. Systém modulů nejprve vezme třídu z modulu patch. Jedná se o stejný efekt jako připojení bootclasspath v Javě 8.

Nepodporovaná chybaClassVersionError

Tato výjimka znamená, že se pokoušíte spustit kód zkompilovaný s novější verzí Javy ve starší verzi Javy. Například používáte Javu 11 s kompilovaným souborem JAR JDK 13.

Verze Javy Verze formátu souboru třídy
8 52
9 53
10 54
11 55
12 56
13 57

Další kroky

Jakmile aplikace běží na Javě 11, zvažte přesunutí knihoven mimo cestu třídy a do cesty modulu. Vyhledejte aktualizované verze knihoven, na které vaše aplikace závisí. Pokud je k dispozici, zvolte modulární knihovny. Použijte cestu modulu co nejvíce, i když neplánujete používat moduly ve vaší aplikaci. Použití modulové cesty má lepší výkon při načítání tříd než cesta tříd.