Megosztás a következőn keresztül:

Váltás Java 8-ról Java 11-re

A Java 8-ról a Java 11-re való átálláshoz nincs mindenre egyformán alkalmazható megoldás. A nem triviális alkalmazások esetében a Java 8-ról a Java 11-re való áttérés jelentős munka lehet. A lehetséges problémák közé tartozik az eltávolított API, az elavult csomagok, a belső API használata, az osztálybetöltők módosítása és a szemétgyűjtés módosítása.

Általánosságban elmondható, hogy a megközelítések: megpróbálni Java 11-en futtatni újrafordítás nélkül, vagy először JDK 11-el fordítani. Ha az a cél, hogy az alkalmazás a lehető leggyorsabban fusson, gyakran a Java 11-en való futtatás a legjobb módszer. A kódtárak esetében a cél egy JDK 11 használatával összeállított és tesztelt összetevő közzététele lesz.

A Java 11-be való áttérés megéri az erőfeszítést. Új funkciók lettek hozzáadva, és fejlesztések történtek a Java 8 óta. Ezek a funkciók és fejlesztések javítják az indítást, a teljesítményt, a memóriahasználatot, és jobb integrációt biztosítanak a tárolókkal. Emellett az API-nak vannak olyan kiegészítései és módosításai, amelyek javítják a fejlesztői hatékonyságot.

Ez a dokumentum a kód vizsgálatához szükséges eszközöket érinti. Emellett az esetlegesen felmerülő problémákat és azok megoldására vonatkozó javaslatokat is tartalmaz. Más útmutatókat is meg kell tekintenie, például az Oracle JDK migrálási útmutatót. A meglévő kód modulárissá tétele itt nem szerepel.

Az eszközkészlet

A Java 11 két olyan eszközzel rendelkezik, jdeprscan és jdeps, amelyek hasznosak a lehetséges problémák feltárására. Ezek az eszközök futtathatók meglévő osztály- vagy jar-fájlokon. Az átállási erőfeszítéseket újrafordítás nélkül is felmérheti.

A jdeprscan elavult vagy eltávolított API-kat keres. Az elavult API használata nem blokkolja a problémát, de ezt meg kell vizsgálni. Van frissített jar-fájl? Jelentenie kell egy problémát az elavult API használatának kezeléséhez? Az eltávolított API használata blokkolási probléma, amelyet a Java 11-es futtatás előtt meg kell oldani.

jdeps, amely egy Java-osztály függőségelemzője. A beállítás használatakor a --jdk-internalsjdeps megmutatja, hogy melyik osztály függ a belső API-tól. Továbbra is használhat belső API-t a Java 11-ben, de a használat lecserélése prioritást élvez. Az OpenJDK wiki oldal Java Dependency Analysis Tool-ja ajánlott cseréket tartalmaz néhány gyakran használt JDK belső API számára.

Vannak jdeps és jdeprscan beépülő modulok a Gradle és a Maven számára is. Javasoljuk, hogy ezeket az eszközöket hozzáadja a buildszkriptekhez.

Eszköz Gradle beépülő modul Maven bővítmény
jdeps jdeps-gradle-plugin Apache Maven JDeps beépülő modul
jdeprscan jdeprscan-gradle-plugin Apache Maven JDeprScan beépülő modul

Maga a Java fordító, a Javac egy másik eszköz az eszközkészletben. A jdeprscan és jdeps által generált figyelmeztetések és hibák a fordító kimeneteként jelennek meg. A jdeprscan és a jdeps használatának előnye, hogy ezeket az eszközöket futtathatja meglévő jars- és osztályfájlokon, beleértve a külső kódtárakat is.

A jdeprscan és a jdeps nem képes arra, hogy figyelmeztessen a tükröződés használatára a beágyazott API eléréséhez. A rendszer futásidőben ellenőrzi a reflektív hozzáférést. Végül a kódot a Java 11-en kell futtatnia, hogy biztosan tudja.

A jdeprscan használata

A jdeprscan használatának legegyszerűbb módja egy jar-fájl átadása egy meglévő buildből. Megadhat egy könyvtárat is, például a fordító kimeneti könyvtárát vagy egy külön osztálynevet. Ezzel a --release 11 beállítással lekérheti az elavult API teljes listáját. Ha rangsorolni szeretné, melyik elavult API-ra összpontosítson, állítsa vissza a beállítást a következő helyre --release 8. A Java 8-ban elavult API valószínűleg hamarabb el lesz távolítva, mint a közelmúltban elavult API.

jdeprscan --release 11 my-application.jar

A jdeprscan eszköz hibaüzenetet hoz létre, ha probléma van egy függő osztály megoldásával. Például: error: cannot find class org/apache/logging/log4j/Logger. Javasolt a függő osztályok hozzáadása az --class-path-hoz vagy az alkalmazás osztály-elérési útjának használata, de az eszköz enélkül is folytatja a vizsgálatot. Az argumentum --class-path. Az osztályútvonal argumentumának más változatai nem fognak működni.

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

Ez a kimenet azt jelzi, hogy az com.company.Util osztály az java.lang.Double osztály elavult konstruktorát hívja meg. A javadoc ajánlott API-t javasol az elavult API helyett. A error: cannot find class sun/misc/BASE64Encoder probléma nem oldható meg, mert az API el lett távolítva. Mivel Java 8, java.util.Base64 kell használni.

Futtassa jdeprscan --release 11 --list, hogy képet kapjon arról, mely API-kat vezették ki a Java 8 óta. Az eltávolított API-k listájának lekéréséhez futtassa a parancsot jdeprscan --release 11 --list --for-removal.

JDEPS használata

A jdeps parancs --jdk-internals opciójával megkeresheti a függőségeket a JDK belső API-kon. A parancssori beállításra --multi-release 11 azért van szükség ebben a példában, mert log4j-core-2.13.0.jar egy több kiadású jar-fájl. E lehetőség nélkül a jdeps panaszkodni fog, ha több kiadású jar-fájlt talál. A beállítás megadja, hogy az osztályfájlok melyik verzióját kell megvizsgálni.

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

A kimenet jó tanácsokat ad a JDK belső API használatának megszüntetéséhez! Ahol lehetséges, a helyettesítő API-t javasoljuk. Annak a modulnak a neve, amelyben a csomag beágyazva van, zárójelben van megadva. A modul neve használható a --add-exports vagy a --add-opens hivatkozásokkal, ha szükséges a kapszulázás explicit megszakítása.

A sun.misc.BASE64Encoder vagy a sun.misc.BASE64Decoder használata java.lang.NoClassDefFoundError eredményt ad a Java 11-ben. Az ezen API-kat használó kódot módosítani kell a java.util.Base64 használatához.

Próbálja meg kiküszöbölni a jdk.unsupported modulból származó API használatát. A modulból származó API javasolt csereként a JDK Enhancement Proposal (JEP) 260-ra hivatkozik. Dióhéjban a JEP 260 azt mondja, hogy a belső API használata támogatott lesz, amíg a helyettesítő API el nem érhető. Annak ellenére, hogy a kód JDK belső API-t használhat, továbbra is futni fog legalább egy ideig. Tekintse meg a JEP 260-at, mivel bizonyos belső API-k cseréjére utal. a változófogópontok például a sun.misc.Unsafe API helyett használhatók.

A jdeps több feladatot is el tud látni, nemcsak a JDK-belsők használatának vizsgálatát. Hasznos eszköz a függőségek elemzéséhez és modulinformációs fájlok létrehozásához. További információért tekintse meg a dokumentációt .

Javac használata

A JDK 11-zel való összeállításhoz frissítésekre lesz szükség a szkriptek, eszközök, tesztelési keretrendszerek és a belefoglalt kódtárak létrehozásához. -Xlint:unchecked A javac beállítással lekérheti a JDK belső API-k és egyéb figyelmeztetések használatának részleteit. Lehetséges, hogy szükséges a --add-opens vagy --add-reads használata a beágyazott csomagok fordító számára való elérhetővé tételéhez (lásd JEP 261).

A könyvtárak a csomagolást több kiadású jar-fájlként tekinthetik. A több kiadású jar-fájlok lehetővé teszik a Java 8 és a Java 11 futtatókörnyezetek támogatását ugyanabból a jar-fájlból. Összetettebbé teszik a buildet. A több kiadású jarok létrehozása meghaladja a dokumentum hatókörét.

Java 11 futtatása

A legtöbb alkalmazásnak módosítás nélkül kell futnia a Java 11-en. Az első dolog, amit meg kell próbálni, hogy Java 11-en futtatjuk a kódot anélkül, hogy újrafordítanánk. A futtatás lényege, hogy megtekintsük, milyen figyelmeztetések és hibák jönnek ki a végrehajtásból. Ez a megközelítés kap egy
Az alkalmazás gyorsabb futtatásához Java 11-en a szükséges minimumra kell összpontosítani.

Az esetleges problémák többsége újrafordítás nélkül is megoldható. Ha egy hibát ki kell javítani a kódban, végezze el a javítást, de folytassa a fordítást a JDK 8 használatával. Ha lehetséges, dolgozzon azon, hogy az alkalmazás a 11-es verzióval java a JDK 11 összeállítása előtt.

Parancssori beállítások ellenőrzése

A Java 11-en való futtatás előtt végezze el a parancssori beállítások gyors vizsgálatát. Az eltávolított beállítások miatt a Java virtuális gép (JVM) kilép. Ez az ellenőrzés különösen fontos, ha GC-naplózási beállításokat használ, mivel ezek drasztikusan megváltoztak a Java 8-ról. A JaCoLine eszköz jól használható a parancssori beállításokkal kapcsolatos problémák észlelésére.

Külső kódtárak ellenőrzése

A probléma lehetséges forrása olyan külső kódtárak, amelyeket nem ön irányít. A külső kódtárakat proaktív módon frissítheti újabb verziókra. Vagy megnézheti, hogy mit eredményez az alkalmazás futtatása, és csak a szükséges könyvtárakat frissítheti. Az összes kódtár legutóbbi verzióra való frissítésével az a probléma, hogy megnehezíti a kiváltó ok megtalálását, ha valamilyen hiba történik az alkalmazásban. A hiba valamilyen frissített kódtár miatt történt? Vagy a hibát valamilyen változás okozta a futtatókörnyezetben? A csak a szükséges frissítéssel kapcsolatos probléma az, hogy több iterációt is igénybe vehet a probléma megoldása.

Az itt található javaslat az, hogy a lehető legkevesebb módosítást végezze el, és külön erőfeszítésként frissítse a külső kódtárakat. Ha frissíti a külső kódtárat, gyakran a Java 11-gyel kompatibilis legújabb és legfejlettebb verziót szeretné használni. Attól függően, hogy milyen messze van az aktuális verzió, érdemes megfontolni egy óvatosabb megközelítést, és frissíteni az első Java 9+ kompatibilis verzióra.

A kibocsátási megjegyzések megtekintésén kívül jdeps és jdeprscan használatával is felmérheti a jar-fájlt. Emellett az OpenJDK minőségi csoport egy minőségi outreach wikilapot is fenntart, amely felsorolja számos ingyenes nyílt forráskódú szoftver (FOSS) projekt tesztelésének állapotát az OpenJDK-verziókon.

A szemétgyűjtés explicit beállítása

A Párhuzamos szemétgyűjtő (Parallel GC) a Java 8 alapértelmezett GC-je. Ha az alkalmazás az alapértelmezett beállítást használja, akkor a GC-t explicit módon meg kell adni a parancssori opcióval -XX:+UseParallelGC. A Java 9-ben az alapértelmezett szemétgyűjtő a Garbage First (G1GC) lett. A Java 8-on futó alkalmazások és a Java 11 igazságos összehasonlításához a GC beállításainak meg kell egyeznie. A GC-beállításokkal való kísérletezést el kell halasztani, amíg az alkalmazás nem lett érvényesítve a Java 11-ben.

Az alapértelmezett beállítások explicit beállítása

Ha a HotSpot virtuális gépen fut, a parancssori beállítás -XX:+PrintCommandLineFlags beállítása a virtuális gép által beállított beállítások értékeit fogja kihozni, különösen a csoportházirend-objektum által beállított alapértelmezett értékeket. Futtassa ezzel a kapcsolóval Java 8-on, és használja a kiírt beállításokat, amikor Java 11-en futtatja. Az alapértelmezett értékek általában 8 és 11 között változnak. A 8-ból származó beállítások használata azonban biztosítja a paritást.

A parancssori opció --illegal-access=warn megadása ajánlott. A Java 11-ben a JDK belső API-hoz való hozzáférés tükrözése szabálytalan visszaverő hozzáférési figyelmeztetést eredményez. Alapértelmezés szerint a figyelmeztetés csak az első illegális hozzáférésre vonatkozik. A beállítás --illegal-access=warn figyelmeztetést fog kelteni minden illegális tükröző hozzáféréssel kapcsolatban. További esetet fog találni, ha az illegális hozzáférés a figyelmeztetésre beállított beállítással történik. De sok redundáns figyelmeztetést is kap.
Miután az alkalmazás a Java 11-en fut, állítsa be a --illegal-access=deny-t úgy, hogy az a Java futtatókörnyezet jövőbeli viselkedését utánozza. A Java 16-tól kezdve az alapértelmezett érték a következő lesz --illegal-access=deny: .

A ClassLoader figyelmeztetései

A Java 8-ban a rendszerosztály-betöltőt át lehet alakítani egy URLClassLoader-re. Ezt általában olyan alkalmazások és kódtárak végzik, amelyek futásidőben szeretnének osztályokat injektálni az osztályútba. Az osztálybetöltő hierarchiája megváltozott a Java 11-ben. A rendszerosztály-betöltő (más néven az alkalmazásosztály-betöltő) mostantól belső osztály. Típuskonverzió egy URLClassLoader dobni fog egy ClassCastException futási időben. A Java 11 nem rendelkezik API-val, amely lehetővé tenné az osztályút futásidőben történő dinamikus bővítését, de a belső API-k használatával kapcsolatos nyilvánvaló kikötésekkel elvégezhető.

A Java 11-ben a rendszerindítási osztály betöltője csak az alapvető modulokat tölti be. Ha null szülővel hoz létre osztálybetöltőt, előfordulhat, hogy nem találja meg valamennyi platformosztályt. Java 11-ben ilyen esetekben a ClassLoader.getPlatformClassLoader() helyett a null-t kell megadnia szülőosztály-betöltőként.

Területi adatok változásai

A Java 11-ben a területi adatok alapértelmezett forrását a 252-s JEP-vel módosították a Unicode Consortium Common Locale Data Repository-jára. Ez hatással lehet a honosított formázásra. Állítsa be a rendszertulajdonságot java.locale.providers=COMPAT,SPI úgy, hogy szükség esetén visszaállítsa a Java 8 területi viselkedését.

Lehetséges problémák

Az alábbiakban néhány gyakori problémát talál. Ezekről a problémákról további részletekért kövesse a hivatkozásokat.

Ismeretlen beállítások

Ha egy parancssori beállítás el lett távolítva, az alkalmazás kinyomtatja Unrecognized option: vagy Unrecognized VM option, amit követ az érintett beállítás neve. Egy ismeretlen beállítás miatt a virtuális gép ki fog lépni. Az elavult, de nem eltávolított beállítások virtuálisgép-figyelmeztetést eredményeznek.

Általánosságban elmondható, hogy az eltávolított beállítások nem rendelkeznek cserével, és az egyetlen megoldás a lehetőség eltávolítása a parancssorból. Kivételt képeznek a szemétgyűjtő naplózásának lehetőségei. A GC-naplózás a Java 9-ben újra lett alkalmazva az egyesített JVM-naplózási keretrendszer használatára. Tekintse meg a "2-2. táblázat: A régi szemétgyűjtési naplózási jelzők leképezése az Xlog konfiguratációra" című szakaszt a JVM egyesített naplózási keretrendszerével történő naplózás engedélyezése részben a Java SE 11 Eszközök referenciában.

VM-figyelmeztetések

Az elavult beállítások használata figyelmeztetést eredményez. A beállítás elavult, ha lecserélték, vagy már nem hasznos. Az eltávolított beállításokhoz hasonlóan ezeket a beállításokat is el kell távolítani a parancssorból. A figyelmeztetés VM Warning: Option <option> was deprecated azt jelenti, hogy a lehetőség továbbra is támogatott, de a jövőben el lehet távolítani a támogatást. A továbbiakban nem támogatott beállítás, amely létrehozza a figyelmeztetést VM Warning: Ignoring option. A már nem támogatott beállítások nem befolyásolják a futtatókörnyezetet.

A VM Options Explorer weboldal átfogó listát nyújt azokról az opciókról, amelyeket a Java-hoz a JDK 7 óta hozzáadtak vagy eltávolítottak.

Hiba: Nem sikerült létrehozni a Java virtuális gépet

Ez a hibaüzenet akkor jelenik meg, ha a JVM ismeretlen beállítással találkozik.

FIGYELMEZTETÉS: Illegális tükröző hozzáférési művelet történt

Ha a Java-kód tükröződéssel éri el a JDK belső API-t, a futtatókörnyezet illegális tükröző hozzáférési figyelmeztetést ad ki.

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

Ez azt jelenti, hogy egy modul nem exportálta azt a csomagot, amely tükröződés útján érhető el. A csomag a modulba van ágyazva , és alapvetően belső API-ból áll. A figyelmeztetés első lépésként figyelmen kívül hagyható a Java 11-ben való használathoz és futtatáshoz. A Java 11-futtatókörnyezet lehetővé teszi a tükröző hozzáférést, hogy az örökölt kód továbbra is működjön.

A figyelmeztetés kezeléséhez keressen olyan frissített kódot, amely nem használja a belső API-t. Ha a probléma nem oldható meg frissített kóddal, vagy a --add-exports vagy a --add-opens parancssori lehetőséget használhatja a csomaghoz való hozzáférés megnyitásához. Ezek a lehetőségek lehetővé teszik az egyik modul nem jelentett típusainak elérését egy másik modulból.

Ezzel --add-exports a beállítással a célmodul hozzáférhet a forrásmodul nevesített csomagjának nyilvános típusaihoz. A kód néha a setAccessible(true) használatával éri el a nem nyilvános tagokat és API-kat. Ezt nevezik mély tükröződésnek. Ebben az esetben használja a --add-opens-t, hogy kódja hozzáférjen a csomag nem publikus tagjaihoz. Ha nem biztos abban, hogy --add-export vagy --add-opens elemet használ, kezdje az --add-exporttal.

A --add-exports vagy --add-opens lehetőségeket kerülő megoldásként kell kezelni, nem pedig hosszú távú megoldásként. Ezen lehetőségek használata megszakítja a modulrendszer beágyazását, amelynek célja, hogy megakadályozza a JDK belső API használatát. Ha a belső API el lett távolítva vagy módosul, az alkalmazás sikertelen lesz. Java 16-ban megtagadják a tükröző hozzáférést, kivéve, ha parancssori opciók, például --add-opens lehetővé teszik azt. A jövőbeli viselkedés utánzásához állítsa be a --illegal-access=deny parancssoron.

A fenti példában szereplő figyelmeztetés azért van kiadva, mert a sun.nio.ch modul nem exportálja a java.base csomagot. Más szóval, nincs exports sun.nio.ch; a module-info.java fájlban a modul java.basefájljában. Ez a megoldás a .-val --add-exports=java.base/sun.nio.ch=ALL-UNNAMEDoldható meg. A modulban nem definiált osztályok implicit módon a meg nem nevezett , szó szerint elnevezett ALL-UNNAMEDmodulhoz tartoznak.

java.lang.reflect.InaccessibleObjectException

Ez a kivétel azt jelzi, hogy egy beágyazott osztály mezőjét vagy metódusát próbálja meghívni setAccessible(true) . Előfordulhat, hogy illegális tükröző hozzáférési figyelmeztetést is kap. Ezzel a --add-opens beállítással hozzáférést adhat a kódnak a csomag nem nyilvános tagjai számára. A kivételüzenetben a modul "nem nyitja meg" a csomagot annak a modulnak, amely meghívja a setAccessible-t. Ha a modul "névtelen modul", használja UNNAMED-MODULE célmodulként a --add-opens beállításban.

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

A NoClassDefFoundError valószínűleg egy felosztott csomag, vagy az eltávolított modulokra való hivatkozás okozza.

NoClassDefFoundError, amelyet osztott csomagok okoznak

Az osztott csomagról akkor beszélünk, ha egy csomag több könyvtárban található. A felosztási csomag problémájának tünete, hogy nem található olyan osztály, amelyről tudja, hogy az osztályútvonalon szerepel.

Ez a probléma csak a modulútvonal használatakor fordul elő. A Java-modulrendszer úgy optimalizálja az osztálykeresést, hogy egy csomagot egy elnevezett modulra korlátoz. A futtatókörnyezet előnyben részesíti a modul elérési útját az osztályútvonalon az osztálykeresés során. Ha egy csomag fel van osztva egy modul és az osztály elérési útja között, akkor csak a modullal hajtja végre az osztálykeresést. Ez hibákhoz NoClassDefFound vezethet.

Az osztott csomag keresésének egyszerű módja, ha a modul elérési útját és az osztály elérési útját jdepsbe dugja, és az alkalmazásosztály-fájlok elérési útját használja elérési útként<>. Ha van felosztott csomag, a jdeps a következő figyelmeztetést fogja kinyomtatni: Warning: split package: <package-name> <module-path> <split-path>.

Ez a probléma úgy oldható meg, ha a --patch-module <module-name>=<path>[,<path>] segítségével hozzáadja a felosztott csomagot a nevesített modulhoz.

Java EE- vagy CORBA-modulok használatával okozott NoClassDefFoundError

Ha az alkalmazás Java 8-on fut, de dob egy java.lang.NoClassDefFoundError vagy egy java.lang.ClassNotFoundException, akkor valószínű, hogy az alkalmazás a Java EE- vagy CORBA-modulokból származó csomagot használ. Ezek a modulok elavultak a Java 9-ben, és el lettek távolítva a Java 11-ben.

A probléma megoldásához adjon hozzá egy futtatókörnyezeti függőséget a projekthez.

Eltávolított modul Érintett csomag Javasolt függőség
Java API xml webszolgáltatásokhoz (JAX-WS) java.xml.ws JAX WS RI-futtatókörnyezet
Java-architektúra XML-kötéshez (JAXB) java.xml.bind JAXB-futtatókörnyezet
JavaBeans-aktiválási keretrendszer (JAV) java.activation JavaBeans (TM) aktiválási keretrendszer
Gyakori széljegyzetek java.xml.ws.annotation Javax Annotation API
Közös Objektum Kérés Közvetítő Architektúra (CORBA) java.corba GlassFish CORBA ORB
Java Transaction API (JTA) java.transaction Java Transaction API

-Az Xbootclasspath/p már nem támogatott beállítás

Megszűnt a támogatás -Xbootclasspath/p számára. A --patch-module használható helyette. A --patch-module lehetőséget a JEP 261 ismerteti. Keresse meg a "Patching module content" (Modul tartalmának javítása) címkével ellátott szakaszt. --patch-module használható javac és java az osztályok felülbírálására vagy kiegészítésére egy modulban.

A --patch-module tulajdonképpen a javításmodult a modulrendszer osztálykeresésébe szúrja be. A modulrendszer először a patch modulból fogja az osztályt. Ez ugyanaz a hatás, mint a bootclasspath előre helyezése a Java 8-ban.

Nem támogatottClassVersionError

Ez a kivétel azt jelenti, hogy olyan kódot próbál futtatni, amelyet a Java egy korábbi verziójában fordítottak le. Például Java 11-en futtat egy JDK 13-tal összeállított jart.

Java-verzió Osztályfájl formátum verziója
8 52
9 53
10 54
11 55
12 56
13 57

Következő lépések

Ha az alkalmazás Java 11-en fut, fontolja meg a kódtárak áthelyezését az osztályútvonalról és a modul elérési útjára. Keresse meg az alkalmazás által használt kódtárak frissített verzióit. Ha elérhető, válassza a moduláris kódtárakat. Használja a modul elérési útját a lehető legnagyobb mértékben, még akkor is, ha nem tervez modulokat használni az alkalmazásban. A modulútvonal használata jobb teljesítményt nyújt az osztálybetöltéshez, mint az osztályútvonal.