Az első lépések a 9. java-val és a kirakós projekt második része
- 11.12.15 07:47 •
- ph_piter •
- # 272861 •
- Habrahabr •
- Fordítás •
- 7 •
- 8800
- ugyanaz, mint Forbes, csak jobb.
Némi késés után közzéteszik a cikk második részét a "Jigsaw" és a "Java 9" projektről, amelyet a Codecentric blogban közzétettek. Az első rész fordítása itt található.
Ez a cikk második része azok számára, akik szeretnének jobban megismerni a Homorítófűrész projektet. Az első részben röviden ismertettük, hogy mi a modul, és hogyan moduláltuk a Java Runtime futási idejét. Ezután egy egyszerű példa volt a moduláris alkalmazás összeállítására, csomagolására és futtatására.
Itt megpróbálunk válaszolni a következő kérdésekre:
Vegyük példaként az 1. rész példáját, és folytassuk a munkát. A kód még mindig itt van.
Jogosultság a speciális modulok olvasásához
Így csak a címellenőrző hozzáférhet a zipvalidator API-hoz. Ez az utasítás a csomag szintjén történik, így semmi sem akadályozza meg a hozzáférést egyes csomagok számára, miközben teljes hozzáférést biztosít mások számára. Ezt a gyakorlatot "minősített exportnak" nevezik. Ha a de.codecentric.nastymodule modul megpróbál bármilyen típust elérni a de.codecentric.zipvalidator.api fájlból. akkor lesz egy összeállítási hiba:
Megjegyzés: a program nem esküszik a module-info.java fájlra. mivel a zipvalidátor elvileg exportálhatja a látható csomagokat az nastymodule-ba. Például minősített kivitelt lehet alkalmazni, ha módosítani szeretné az alkalmazás belső struktúráját, de nem szeretné megosztani a belső modulok exportált csomagjait az ügyfelekkel.
A modulváltozatok közötti konfliktusok
Gyakran előfordul, hogy a tranzit függőségeken keresztül a könyvtár különböző verziói ugyanabba az alkalmazásba esnek - azaz ugyanaz a modul kétszer jelenhet meg a modulok elérési útján. Egyszerre két forgatókönyv jut eszembe:
- A modulok fordítási időben különböző könyvtárakban vagy moduláris jarban állnak rendelkezésre, de azonos névvel azonosak
- Az ugyanazon modul különböző verziói eltérő nevek
Próbáljuk összeállítani az alkalmazást az első forgatókönyvben. A zipvalidátor másolása:
A duplikált modulok különböző könyvtárakban vannak, de a modul neve változatlan marad. Hogyan reagál a Jigsaw erre a fordítás során?
Szóval, itt könnyű megszabadulni. A rendszerkészítõ hibaüzenetet hoz létre, ha két modul van ugyanarra a névre a modulok elérési útján.
Mi a helyzet a második ügyben? A könyvtár szerkezete ugyanaz marad, de most mindkét zipvalidator'a kapni különböző nevek (de.codecentric.zipvalidator.v) és addresschecker olvasni mindkét nevet.
A fejlesztő azonnal figyelmen kívül hagyja az ilyen figyelmeztetést és elindítja az alkalmazást. De a Jigsaw nyilvánvalóan nem szereti, amit futás közben lát:
Úgy tűnik számomra érthetetlen, véleményem szerint a fordítási idő hibája rendezhető és óvatosabb. Megkértem a levelezési listát. miért választotta ezt az opciót, de a cikk írásakor még nem kapott választ.
Automatikus modulok és névtelen modul
Eddig teljesen modularizált környezetben dolgoztunk. De mi a teendő ilyen nagyon valószínű esetekben, amikor a nem moduláris Jar-fájlokkal kell foglalkoznod? Itt automatikus modulok és egy névtelen modul jönnek létre.
Kezdjük az automatikus modulokkal. Az automatikus modul a modulpályán szállított jar fájl. Miután írta ott, képes lesz megválaszolni a következő három kérdést a modulról:
K: Mi a neve?
V: Ez a jar fájl neve. Ha a guava.jar fájlt a modulok elérési útjába helyezi, akkor kap egy automatikus guava modult.
Ez azt is jelenti, hogy nem használhatja a Jarot közvetlenül a Maven tárolóból, mivel a guava-18.0 nem érvényes Java azonosító.
K: Mit exportál?
V: Az automatikus modul exportálja az összes csomagját. Tehát minden nyilvános típus elérhető lesz bármely modul számára, amely az automatikus modult olvassa le.
Tekintsünk egy példát. Elkezdtük a com.google.common.base.Strings használatát a zipvalidatorban. A hozzáférés engedélyezéséhez meg kell adnunk az automatikus Guava modul olvasási élét:
A fordításhoz meg kell adnia a guava.jar fájlt a modulok elérési útjában (ez a / jars könyvtárban található):
Minden tökéletesen összeállt és elindult.
(Mellesleg, ez nem volt olyan könnyű futni ebben a példában dolgozik a szerelvény Jigsaw 86 belefutottam néhány problémát :. rendszer megesküdött körülbelül függőségek jdk.management.resource modul megkérdeztem róla a hírlevél, a vita itt található ..
Azt kell mondanom, hogy döntésem során nem használtam a "korai" építést (korai hozzáférés építése), de magam gyűjtöttem a JDK-t. Az OSX Mavericks használatakor még mindig voltak problémák, amint azt a szálon írták, át kellett változtatnom a makefile-t, de végül mindent megtettem. Talán más problémákkal is szembesülhet, ha a következő kiadásokkal dolgozik).
Most van itt az ideje, hogy bemutassam a pálcák segítségét, amely elengedhetetlen a Jigsaw-ban való áttéréshez. Ezt az eszközt jdepsnek hívják. A modulodon keresztül néz ki, és megmondja a függőségeket.
jdeps -s. /jars/guava.jar
A következtetésünk van:
guava.jar -> java.base
guava.jar -> java.logging
guava.jar -> nem található
Ez azt jelenti, hogy az automatikus guava modul java.base-t igényel. java.logging és ... "nem található". Mi ez? Ha eltávolítja a -s kapcsolót. akkor a jdeps elhagyja a modul szintjét és lemegy egy lépéssel a csomag szintjére (a lista enyhén lecsökken, mivel nagyon sok guaó csomag van):
Ez azt mutatja, hogy a com.google.common.xml csomag a com.google.common.escape függvénye. amely a modulban található, java.lang. amely jól ismert, és a javax.annotation megjegyzéséből. amely nem található. Arra a következtetésre jutottunk, hogy szükségünk van egy korsó típusú JSR-305, mivel nem tartalmaz javax.annotation (by the way, én megtenném nélkülük - az én példák, nem kell minden típusú ezeket a csomagokat, sem a fordító, vagy a futási nem objektum).
Tehát mi a névtelen modul? Ismét három kérdésre válaszolunk:
K: Mi a neve?
V: Mint már kitaláltad, nincs név
K: Mit követel?
A: A névtelen modul leolvassa az összes többi rendelkezésre álló modult.
Tehát, ha nem tudod elolvasni egy névtelen modulot bármelyik modulodból, mi a lényeg? A régi barátunk segít nekünk megválaszolni ezt a kérdést - az osztályok útját. Bármilyen típusú olvasható a osztályútvonal (és nem az a módja, hogy a modulok) automatikusan bekerül a gyűrű modul - vagy más szóval, bármilyen típusú modul be van töltve a gyűrűhöz classpath. Mivel az anonim modul az összes többi modult olvassa, az összes exportált típust az osztálypályán keresztül betöltött bármely típusból érheti el. A Java 9-ben az osztályok elérési útját és a modulok elérési útját külön-külön és együttesen támogatják, ezzel biztosítva a kompatibilitást. Nézzünk néhány példát.
Tegyük fel, hogy van egy szép zipvalidator modulunk, de a címellenőrző még mindig nem moduláris, nincs modul-info.java. Forrásaink szerkezete:
Most van egy classpath könyvtár, amely tartalmazza a zipvalidatorhoz való hozzáféréshez kapcsolódó örökölt kódot, valamint a zipvalidator modulot tartalmazó modulpath könyvtárat. A modulokat a szokásos módon fordíthatjuk. Az örökölt kód összeállításához információt kell szolgáltatnunk a modulkódról. Csak írd az osztályokba:
Minden a szokásos módon működik.
- Írja be a modult az osztálypályán
- Keverjük az elérési utat az osztályokhoz és a modulokhoz vezető utat
Az első lehetőség kiválasztásánál valójában elhagyjuk a moduláris rendszert. Minden típus, amelyet a névtelen modulban írunk, mostantól szabadon hozzáférhet egymáshoz.
ugyanúgy működik, mint a ma használatos java alkalmazás.
Másfelől a modulok elérési útjának és az osztályokba való bekötésnek a vegyes használata így működik:
Két kapcsolót használunk egyszerre: -classpath és -modulepath. Hozzáadott -addmods váltani - ha vegyes classpath és az utat, hogy a modulok, akkor nem csak kap hozzáférést bármilyen modult ModulePath könyvtárak és meg kell határoznia, hogy melyikük legyen elérhető.
Ez a megközelítés jól működik, de itt van egy fogás! Ne feledje, hogy a "mi a névtelen modul" kérdésre adott válasz "az összes többi modul". Ha a zipvalidator modulot a modulpályán keresztül használjuk, akkor csak az exportált csomagokkal dolgozhatunk. Minden mást az IllegalAccessError futás közben fut. Ezért ebben az esetben meg kell követnie a modulrendszer szabályait.
A futásidejű képek létrehozása a jlink segítségével
Elég példa a modulokkal; volt még egy új eszköz, ami megérdemli a figyelmet. A jlink Java 9 segédprogram a saját JVM disztribúciók létrehozásához. A legérdekesebb az, hogy a JDK új moduláris architektúrájának köszönhetően kiválaszthatja, mely modulokat kívánja felvenni a terjesztési készletbe! Tekintsünk egy példát. Ha szeretnénk létrehozni egy képet a futási időről, amely a címzettünket tartalmazza, akkor a következő parancsot adjuk meg:
Csak három dolgot említünk:
- A modulok elérési útja (beleértve a speciális moduljainkat és a JDK jmods könyvtárának elérési útját - itt vannak a standard java modulok)
- Azokat a modulokat, amelyeket a terjesztéshez kíván használni
- Kimeneti könyvtár
A parancs a következő struktúrát hozza létre:
linkedjdk /
+-- láda
| + - java
| L-- keytool
+-- conf
| + - net.properties
| L-- biztonság
| + - java.policy
| L-- java.security
L-- lib
+-- classlist
+-- JLI
Ez minden. Az OSX Mavericks esetében mindössze 47 MB. Használhatjuk az archiválást és eltávolíthatjuk azokat a hibakeresési szolgáltatásokat is, amelyekre még nincs szükség a gyártás során. A legkisebb kompromisszumot, amit sikerült létrehoznom, e parancs segítségével kaptam meg:
A disztribúció mérete körülbelül 18 MB-ra csökkent, véleményem szerint - csak remek. A Linuxban valószínűleg 13-an elrejtheted.
A felsorolt modulok listáját jeleníti meg
Így minden olyan alkalmazás, amely e modulok maximális számától függ, működhet ezen a JVM-en. De nem tudtam elkapni a fő osztályunkat a forgatókönyv futtatásához. Erre a másik irányba mentem.
A figyelmes olvasó észrevehette, hogy a második hívás a jlinkre kerül, és a modulok elérési útja más, mint az első hívásnál. A második esetben megadjuk a bin könyvtár elérési útját. Ez a könyvtár moduláris jar-fájlokat tartalmaz, és a címellenőrző jar tartalmazza a manifestben szereplő fő osztály információit is. A jlink segédprogram ezt az információt használja további információkkal a JVM bin könyvtárához:
Tehát most közvetlenül hívhatjuk az alkalmazást. Beauty!
A 76185 érvényes irányítószám
Ez a vége a Jigsaw-nak. Mi tekinthető számos példát, hogy bemutassa, milyen lehet és mit nem lehet tenni a Jigsaw és Java 9. Jigsaw hoz alapvető változásokat nem lehet olyan könnyen kompenzálható a lambda kifejezések, vagy próbálja-erőforrásokkal. Minden olyan összeszerelő eszköz, mint a Maven vagy a Gradle az IDE-ből, alkalmazkodnia kell a moduláris rendszerhez. A JavaOne konferencián Hans Dockter a Gradle Inc.-től olvassa el a Moduláris kód írásának megkezdéséről szóló jelentést, még a Java 8-as vagy újabb verzióiban is. A Gradle elvégzi a fordítási időt, és hibát bocsát ki, ha a modul sértetlenségét megsértették. Ez a (kísérleti) lehetőség a Gradle 2.9 legfrissebb kiadásában szerepelt. Mi biztosan várunk érdekes időkre!