Programovanie

Modularita v prostredí Java 9: ​​Skombinovanie s programami Project Jigsaw, Penrose a OSGi

Tento článok poskytuje prehľad návrhov, špecifikácií a platforiem zameraných na zvýšenie modulárnej technológie Java v prostredí Java 9. Budem diskutovať o faktoroch prispievajúcich k potrebe modulárnejšej architektúry Java, stručne opíšem a porovnám navrhované riešenia, a predstaviť tri aktualizácie modularity plánované pre Java 9 vrátane ich potenciálneho vplyvu na vývoj Java.

Prečo potrebujeme modularitu Java?

Modularita je všeobecný pojem. V softvéri sa uplatňuje na písanie a implementáciu programu alebo výpočtového systému ako množstva jedinečných modulov, a nie ako jeden monolitický dizajn. Potom sa použije štandardizované rozhranie na umožnenie komunikácie modulov. Rozdelenie prostredia softvérových konštruktov na samostatné moduly nám pomáha minimalizovať prepojenie, optimalizovať vývoj aplikácií a znižovať zložitosť systému.

Modularita umožňuje programátorom vykonať testovanie funkčnosti izolovane a zapojiť sa do paralelných vývojových snáh počas daného šprintu alebo projektu. To zvyšuje efektivitu počas celého životného cyklu vývoja softvéru.

Niektoré charakteristické vlastnosti originálneho modulu sú:

  • Autonómna jednotka nasadenia (voľné spojenie)
  • Konzistentná a jedinečná identita (ID modulu a verzia)
  • Ľahko identifikovateľné a objavené požiadavky a závislosti (štandardné zariadenia na kompiláciu a nasadenie a metainformácie)
  • Otvorené a zrozumiteľné rozhranie (komunikačná zmluva)
  • Skryté podrobnosti implementácie (zapuzdrenie)

Systémy postavené na efektívne spracovanie modulov by mali robiť nasledovné:

  • Podporujte modularitu a zisťovanie závislostí v čase kompilácie
  • Spúšťajte moduly v prostredí runtime, ktoré podporuje ľahké nasadenie a opätovné nasadenie bez výpadkov systému
  • Implementujte jasný a robustný životný cyklus vykonania
  • Poskytnite vybavenie na ľahkú registráciu a objavovanie modulov

Objektovo-orientované, komponentovo-orientované a servisne orientované riešenia sa všetky pokúšali umožniť čistú modularitu. Každé riešenie má svoju vlastnú sadu zvláštností, ktoré mu bránia v dosiahnutí modulárnej dokonalosti. Stručne zvážime.

Triedy a objekty Java ako modulárne konštrukcie

Nespĺňa objektovo orientovaná povaha Java požiadavky na modularitu? Objektovo orientované programovanie v prostredí Java napokon zdôrazňuje a niekedy vynucuje jedinečnosť, zapuzdrenie údajov a voľné spojenie. Aj keď sú tieto body dobrým začiatkom, všimnite si požiadavky na modularitu, ktoré nie sú spĺňa objektovo orientovaný rámec Java: identita na úrovni objektu je nespoľahlivá; rozhrania nemajú verziu: a triedy nie sú na úrovni nasadenia jedinečné. Uvoľnené spojenie je osvedčený postup, ale určite sa neuplatňuje.

Opätovné použitie tried v prostredí Java je ťažké, keď sú závislosti tretích strán tak ľahko zneužité. Tento nedostatok sa snažia vyriešiť nástroje na kompiláciu, ako napríklad Maven. Konvencie a konštrukty jazyka ako fakta, ako napríklad vkladanie závislostí a inverzia kontroly, pomáhajú vývojárom pri našich pokusoch o kontrolu runtime prostredia a niekedy sa im to podarí, najmä ak sa používajú s prísnou disciplínou. Táto situácia, bohužiaľ, ponecháva prácu na vytváraní modulárneho prostredia až po konvencie a konfigurácie rámcového vlastníctva.

Java tiež pridáva do zmesi menné priestory balíkov a viditeľnosť rozsahu ako prostriedok na vytváranie modulárnych mechanizmov kompilácie a nasadenia. Ale ako vysvetlím, týmto jazykovým funkciám sa dá ľahko vyhnúť.

Balíky ako modulárne riešenie

Balíky sa snažia pridať úroveň abstrakcie do programovacieho prostredia Java. Poskytujú vybavenie pre jedinečné kódovacie menné priestory a konfiguračné kontexty. Je však smutné, že konvencie balíkov sa dajú ľahko obísť, čo často vedie k prostrediu nebezpečných prepojení v čase kompilácie.

Stav modularity v Jave sa v súčasnosti (okrem OSGi, o ktorom sa budem krátko venovať) najčastejšie dosahuje použitím menných priestorov balíkov, konvencií JavaBeans a proprietárnych konfigurácií rámca, aké sa nachádzajú na jar.

Nie sú súbory JAR dostatočne modulárne?

Súbory JAR a prostredie nasadenia, v ktorom fungujú, výrazne vylepšujú mnohé staršie konvencie nasadenia, ktoré sú inak dostupné. Súbory JAR však nemajú vnútornú jedinečnosť, okrem zriedka používaného čísla verzie, ktoré je skryté v manifeste .jar. Súbor JAR a voliteľný manifest sa v prostredí runtime Java nepoužívajú ako konvencie modularity. Takže názvy balíkov tried v súbore a ich účasť na ceste triedy sú jedinými časťami štruktúry JAR, ktoré prepožičiavajú runtime prostredie modulárnosť.

Stručne povedané, súbory JAR sú dobrým pokusom o modularizáciu, ale nespĺňajú všetky požiadavky na skutočne modulárne prostredie. Rámec a platformy ako Spring a OSGi používajú vzory a vylepšenia špecifikácie JAR na zabezpečenie prostredí pre budovanie veľmi schopných a modulárnych systémov. Postupom času však aj tieto nástroje podľahnú veľmi nešťastnému vedľajšiemu efektu špecifikácie JAR, pekla JAR!

Classpath / JAR peklo

Keď prostredie runtime Java umožňuje ľubovoľne zložité mechanizmy načítania JAR, vývojári vedia, že sa v ňom nachádzajú triedna cesta peklo alebo JAR do pekla. K tejto podmienke môže viesť niekoľko konfigurácií.

Najskôr zvážte situáciu, keď vývojár aplikácií Java poskytne aktualizovanú verziu aplikácie a zabalil ju do súboru JAR s presne rovnakým názvom ako stará verzia. Runtime prostredie Java neposkytuje žiadne overovacie prostriedky na určenie správneho súboru JAR. Runtime prostredie jednoducho načíta triedy zo súboru JAR, ktorý nájde ako prvý alebo ktorý spĺňa jedno z mnohých pravidiel triedy. To vedie v lepšom prípade k neočakávanému správaniu.

Ďalšia inštancia pekla JAR nastáva, keď dve alebo viac aplikácií alebo procesov závisí od rôznych verzií knižnice tretej strany. Pri použití štandardných zariadení na načítanie tried bude za behu aplikácie k dispozícii iba jedna verzia knižnice tretej strany, čo povedie k chybám aspoň v jednej aplikácii alebo procese.

Plnohodnotný a efektívny systém modulov Java by mal uľahčiť rozdelenie kódu na samostatné, ľahko pochopiteľné a voľne spojené moduly. Závislosti by mali byť jasne špecifikované a prísne vymáhané. Mali by byť k dispozícii zariadenia, ktoré umožňujú upgrade modulov bez toho, aby to malo negatívny vplyv na ostatné moduly. Modulárne runtime prostredie by malo umožňovať konfigurácie, ktoré sú špecifické pre konkrétnu doménu alebo vertikálny trh, čím by sa znížil čas spustenia a systémová stopa prostredia.

Modulárne riešenia pre Javu

Spolu s doteraz spomenutými funkciami modularity pridávajú posledné snahy ešte niekoľko ďalších. Nasledujúce funkcie sú určené na optimalizáciu výkonu a povolenie rozšírenia runtime prostredia:

  • Segmentovaný zdrojový kód: Zdrojový kód rozdelený do samostatných segmentov vo vyrovnávacej pamäti, z ktorých každý obsahuje konkrétny typ skompilovaného kódu. Medzi ich ciele patrí preskakovanie kódu, ktorý nie je metódou, počas odstraňovania odpadu, prírastkové vytváranie a lepšia správa pamäte.
  • Presadzovania v čase zostavenia: Jazykové konštrukcie na vynucovanie menných priestorov, vytváranie verzií verzií, závislostí a ďalšie.
  • Nasadzovacie zariadenia: Podpora nasadenia zmenšených runtime prostredí podľa konkrétnych potrieb, ako sú napríklad prostredie mobilných zariadení.

O uľahčenie týchto funkcií sa usilovalo množstvo špecifikácií a rámcov modularity a niektoré sa nedávno dostali na popredné priečky v návrhoch pre Java 9. Nižšie je uvedený prehľad návrhov v oblasti Java.

JSR (Java Specification Request) 277

Momentálne neaktívna je Java Specification Request (JSR) 277, Java Module System; predstavila spoločnosť Sun v júni 2005. Táto špecifikácia zahŕňala väčšinu rovnakých oblastí ako OSGi. Rovnako ako OSGi, aj JSR 277 definuje objavovanie, načítanie a konzistenciu modulov s riedkou podporou runtime úprav a / alebo kontroly integrity.

Nevýhody JSR 277 zahŕňajú:

  • Žiadne dynamické načítanie a vyloženie modulov / zväzkov
  • Žiadna runtime kontrola jedinečnosti triedneho priestoru

OSGi (iniciatíva Open Service Gateway)

Platforma OSGI, ktorú predstavila Aliancia OSGI v novembri 1998, je najbežnejšie používanou odpoveďou na modularitu formálnej štandardnej otázky pre Javu. V súčasnosti vo vydaní 6 je špecifikácia OSGi všeobecne prijímaná a používaná, najmä neskoro.

OSGi je v podstate modulárny systém a platforma služieb pre programovací jazyk Java, ktorá implementuje kompletný a dynamický model súčiastky vo forme modulov, služieb, nasaditeľných zväzkov atď.

Primárne vrstvy architektúry OSGI sú nasledujúce:

  • Realizačné prostredie: Prostredie Java (napríklad Java EE alebo Java SE), pod ktorým bude balík bežať.
  • Modul: Kde rámec OSGi spracováva modulárne aspekty zväzku. Tu sa spracúvajú metadáta zväzku.
  • Životný cyklus: Tu sa deje inicializácia, spustenie a zastavenie zväzkov.
  • Servisný register: Kde zväzky uvádzajú svoje služby, aby ich mohol vyhľadať ďalší zväzok.

Jednou z najväčších nevýhod OSGi je nedostatok formálneho mechanizmu pre inštaláciu natívnych balíkov.

JSR 291

JSR 291 je dynamický komponentový rámec pre Java SE, ktorý je založený na OSGi, je v súčasnej dobe v konečnej fáze vývoja. Toto úsilie sa zameriava na začlenenie OSGi do bežnej Javy, ako to urobilo pre mobilné prostredie Java JSR 232.

JSR 294

JSR 294 definuje systém meta-modulov a deleguje skutočné uskutočnenie zásuvných modulov (verzie, závislosti, obmedzenia atď.) Na externých poskytovateľov. Táto špecifikácia zavádza jazykové rozšírenia, ako napríklad „superbalíky“ a hierarchicky súvisiace moduly, aby uľahčila modularitu. Súčasťou zamerania špecifikácie je aj prísna enkapsulácia a zreteľné kompilačné jednotky. JSR 294 je momentálne v nečinnosti.

Projekt Skladačka

Projekt Jigsaw je najpravdepodobnejším kandidátom na modularitu v prostredí Java 9. Spoločnosť Jigsaw sa snaží pomocou jazykových konštruktov a konfigurácií prostredia definovať škálovateľný modulový systém pre Java SE. Medzi hlavné ciele hry Jigsaw patria:

  • Vďaka tomu je veľmi ľahké škálovať runtime Java SE a JDK na malé zariadenia.
  • Zlepšenie bezpečnosti Java SE a JDK zákazom prístupu k interným API JDK a vynútením a vylepšením SecurityManager.checkPackageAccess metóda.
  • Zlepšenie výkonu aplikácie prostredníctvom optimalizácie existujúceho kódu a uľahčenie techník optimalizácie výhľadových programov.
  • Zjednodušenie vývoja aplikácií v prostredí Java SE umožnením konštruovania knižníc a aplikácií z modulov prispievaných vývojármi a z modulárneho JDK
  • Vyžadovanie a presadzovanie konečnej sady obmedzení verzie

JEP (Návrh vylepšenia Java) 200

Návrh Java Enhancement 200, ktorý bol vytvorený v júli 2014, sa snaží definovať modulárnu štruktúru pre JDK. JEP 200 stavia na rámci Jigsaw, aby uľahčil segmentáciu JDK, podľa Java 8 Compact Profiles, na sady modulov, ktoré je možné kombinovať v čase kompilácie, zostavenia a nasadenia. Tieto kombinácie modulov je potom možné nasadiť ako zmenšené runtime prostredia, ktoré sú zložené z modulov kompatibilných s programom Jigsaw.

JEP 201

JEP 201 sa snaží nadviazať na program Jigsaw a reorganizovať zdrojový kód JDK na moduly. Tieto moduly je potom možné kompilovať ako samostatné jednotky pomocou vylepšeného systému zostavovania, ktorý vynucuje hranice modulov. JEP 201 navrhuje reštrukturalizačnú schému zdrojového kódu v celej JDK, ktorá zdôrazňuje hranice modulov na najvyššej úrovni stromov zdrojových kódov.

Penrose

Penrose bude riadiť interoperabilitu medzi programami Jigsaw a OSGi. Konkrétne by to uľahčilo schopnosť modifikovať mikrok jadrá OSGi, aby zväzky bežiace v upravenom jadre využívali moduly Jigsaw. Pri opise modulov sa spolieha na použitie JSON.

Plány pre Javu 9

Java 9 je jedinečné hlavné vydanie pre Javu. Vďaka čomu je jedinečný, predstavuje zavedenie modulárnych komponentov a segmentov počas celého JDK. Primárne funkcie podporujúce modularizáciu sú:

  • Modulárny zdrojový kód: V prostredí Java 9 budú JRE a JDK reorganizované do interoperabilných modulov. To umožní vytvorenie škálovateľných runtime, ktoré je možné vykonať na malých zariadeniach.
  • Segmentovaná medzipamäť kódu: Aj keď nejde o striktne modulárne zariadenie, nová segmentovaná vyrovnávacia pamäť kódu Java 9 bude nasledovať ducha modularizácie a bude využívať niektoré z rovnakých výhod. Nová vyrovnávacia pamäť kódov bude robiť inteligentné rozhodnutia o kompilácii často prístupných segmentov kódu do natívneho kódu a ukladať ich na optimalizované vyhľadávanie a budúce vykonávanie. Halda bude tiež segmentovaná do 3 samostatných jednotiek: kód bez metódy, ktorý bude trvale uložený v pamäti cache; kód, ktorý má potenciálne dlhý životný cyklus (známy ako „neprofilovaný kód“); a kód, ktorý je prechodný (známy ako „profilovaný kód“).
  • Presadzovania v čase zostavenia: Systém zostavovania bude vylepšený prostredníctvom JEP 201 o kompiláciu a vynútenie hraníc modulov.
  • Nasadzovacie zariadenia: V rámci projektu Jigsaw budú poskytované nástroje, ktoré budú v čase nasadenia podporovať hranice, obmedzenia a závislosti modulov.

Vydanie predčasného prístupu Java 9

Aj keď presný dátum vydania Java 9 zostáva záhadou, vydanie pre skorý prístup si môžete stiahnuť na stránke Java.net.

Na záver

Tento článok predstavuje prehľad modularity v rámci platformy Java, vrátane vyhliadok na modularitu v prostredí Java 9. Vysvetlil som, ako dlhotrvajúce problémy, ako je napríklad classpath hell, prispievajú k potrebe modulárnejšej architektúry Java, a diskutoval som o niektorých najnovších nových modulárnostiach. funkcie navrhnuté pre Javu. Potom som opísal a kontextualizoval každý z návrhov alebo platforiem Java modularity, vrátane OSGi a Project Jigsaw.

Potreba modulárnejšej architektúry Java je zrejmá. Súčasné pokusy zaostávajú, aj keď OSGi je veľmi blízko. Pri vydaní Java 9 budú Project Jigsaw a OSGi hlavnými hráčmi v modulárnom priestore pre Javu, pričom medzi nimi môže byť lepidlo Penrose.

Tento príbeh „Modularita v prostredí Java 9: ​​Stacking up with Project Jigsaw, Penrose a OSGi“ bol pôvodne publikovaný spoločnosťou JavaWorld.

$config[zx-auto] not found$config[zx-overlay] not found