Ta članek vsebuje pregled predlogov, specifikacij in platform, katerih namen je Java tehnologija postati bolj modularna v Javi 9. Obravnaval bom dejavnike, ki prispevajo k potrebi po bolj modularni arhitekturi Java, na kratko opisal in primerjal predlagane rešitve, in predstaviti tri posodobitve modularnosti, načrtovane za Javo 9, vključno z njihovim potencialnim vplivom na razvoj Jave.
Zakaj potrebujemo modularnost Java?
Modularnost je splošen pojem. V programski opremi se nanaša na pisanje in izvajanje programa ali računalniškega sistema kot več edinstvenih modulov in ne kot eno samo monolitno zasnovo. Nato se za komunikacijo modulov uporablja standardiziran vmesnik. Razdeljevanje okolja programskih konstruktov na ločene module nam pomaga zmanjšati povezovanje, optimizirati razvoj aplikacij in zmanjšati kompleksnost sistema.
Modularnost programerjem omogoča, da samostojno preizkušajo funkcionalnost in sodelujejo v vzporednih razvojnih prizadevanjih med danim sprintom ali projektom. To povečuje učinkovitost skozi celoten življenjski cikel razvoja programske opreme.
Nekateri značilni atributi pristnega modula so:
- Avtonomna enota za razporeditev (ohlapna sklopka)
- Dosledna in edinstvena identiteta (ID modula in različica)
- Preprosto prepoznane in odkrite zahteve in odvisnosti (standardni čas prevajanja in naprave za uvajanje ter meta-informacije)
- Odprt in razumljiv vmesnik (komunikacijska pogodba)
- Skrite podrobnosti izvedbe (enkapsulacija)
Sistemi, ki so zgrajeni za učinkovito obdelavo modulov, bi morali narediti naslednje:
- Podpira modularnost in odkrivanje odvisnosti v času prevajanja
- Izvajajte module v izvajalnem okolju, ki podpira enostavno uvajanje in prerazporeditev brez izpadov sistema
- Izvedite izvedbeni življenjski cikel, ki je jasen in zanesljiv
- Zagotovite pripomočke za enostavno registracijo in odkrivanje modulov
Predmetno usmerjene, komponentne in storitveno usmerjene rešitve so skušale omogočiti čisto modularnost. Vsaka rešitev ima svoj nabor domislic, ki ji preprečujejo doseganje modularne popolnosti. Na kratko razmislimo.
Razredi in predmeti Java kot modularni konstrukti
Ali objektno usmerjena narava Jave ne ustreza zahtevam modularnosti? Navsezadnje objektno usmerjeno programiranje z Javo poudarja in včasih uveljavlja edinstvenost, inkapsulacijo podatkov in ohlapno povezovanje. Čeprav so te točke dober začetek, upoštevajte zahteve glede modularnosti, ki jih niso ki ga izpolnjuje objektno usmerjen okvir Java: identiteta na ravni objekta je nezanesljiva; vmesniki niso različni: in razredi na ravni uvajanja niso edinstveni. Ohlapno spenjanje je najboljša praksa, vendar se zagotovo ne izvaja.
Ponovna uporaba predavanj v Javi je težka, če so odvisnosti drugih proizvajalcev tako enostavno zlorabljene. Programska orodja, kot je Maven, skušajo odpraviti to pomanjkljivost. Jezikovne konvencije in konstrukti, kot sta vbrizgavanje odvisnosti in inverzija nadzora, pomagajo razvijalcem pri naših poskusih nadzora nad izvajalnim okoljem in včasih uspejo, zlasti če se uporabljajo s strogo disciplino. Na žalost je zaradi tega treba ustvarjati modularno okolje do lastniških okvirnih konvencij in konfiguracij.
Java tudi mešanici doda imenske prostore paketov in vidnost obsega kot sredstvo za ustvarjanje modularnih mehanizmov za čas prevajanja in časa uvajanja. Toda, kot bom razložil, se te jezikovne lastnosti zlahka izognejo.
Paketi kot modularna rešitev
Paketi poskušajo dodati programsko krajino ravni abstrakcije. Omogočajo edinstvene prostore kodiranja imenskih prostorov in konfiguracijskih kontekstov. Žal pa se paketnim konvencijam lahko izognemo, kar pogosto vodi v okolje nevarnih sklopk za čas prevajanja.
Trenutno stanje modularnosti v Javi (razen OSGi, o katerem bom kmalu razpravljal) se najpogosteje doseže z uporabo imenskih prostorov paketov, konvencij JavaBeans in lastniških konfiguracij ogrodja, kakršne najdemo spomladi.
Ali datoteke JAR niso dovolj modularne?
Datoteke JAR in razmestitveno okolje, v katerem delujejo, močno izboljšajo številne obstoječe konvencije o uvajanju, ki so sicer na voljo. Datoteke JAR pa nimajo nobene posebne edinstvenosti, razen redko uporabljene številke različice, ki je skrita v manifestu .jar. Datoteka JAR in neobvezni manifest se ne uporabljata kot pravila modularnosti v okolju Java. Tako so imena paketov razredov v datoteki in njihovo sodelovanje v razredni poti edini deli strukture JAR, ki dajejo modularnost izvajalnemu okolju.
Skratka, JAR-ji so dober poskus modularizacije, vendar ne izpolnjujejo vseh zahtev za resnično modularno okolje. Okviri in platforme, kot sta Spring in OSGi, uporabljajo vzorce in izboljšave specifikacije JAR, da zagotovijo okolja za gradnjo zelo zmogljivih in modularnih sistemov. Sčasoma pa bodo tudi ta orodja podlegla zelo žalostnemu stranskemu učinku pekla JAR specifikacije JAR!
Classpath / JAR pekel
Ko izvajalno okolje Java omogoča poljubno zapletene mehanizme za nalaganje JAR, razvijalci vedo, da so v njem učilnica pekel ali JAR pekel. Številne konfiguracije lahko privedejo do tega stanja.
Najprej razmislimo o situaciji, ko razvijalec aplikacije Java ponuja posodobljeno različico aplikacije in jo zapakira v datoteko JAR s popolnoma enakim imenom kot stara različica. Izvajalno okolje Java ne ponuja možnosti preverjanja veljavnosti za določitev pravilne datoteke JAR. Izvajalno okolje bo preprosto naložilo razrede iz datoteke JAR, ki jo najde najprej ali ki izpolnjuje eno od mnogih pravil razredov. To v najboljšem primeru vodi do nepričakovanega vedenja.
Še en primer pekla JAR se pojavi, ko sta dve ali več aplikacij ali procesov odvisni od različnih različic neodvisne knjižnice. Z uporabo standardnih naprav za nalaganje razredov bo med izvajanjem na voljo samo ena različica neodvisne knjižnice, kar bo povzročilo napake v vsaj eni aplikaciji ali procesu.
Popolnoma opremljen in učinkovit sistem modulov Java bi moral olajšati ločevanje kode na ločene, lahko razumljive in ohlapno povezane module. Odvisnosti bi morale biti natančno določene in dosledno izvršene. Na voljo morajo biti naprave, ki omogočajo nadgradnjo modulov, ne da bi to negativno vplivalo na druge module. Modularno izvajalno okolje mora omogočati konfiguracije, ki so specifične za določeno domeno ali navpični trg, s čimer se skrajša čas zagona in sistemski odtis okolja.
Rešitve modularnosti za Javo
Poleg doslej omenjenih funkcij modularnosti so nedavna prizadevanja dodala še nekaj. Naslednje funkcije so namenjene optimizaciji zmogljivosti in omogočanju razširitve okolja izvajalnega okolja:
- Segmentirana izvorna koda: Izvorna koda, ločena v ločene, predpomnjene segmente, od katerih vsak vsebuje določeno vrsto prevedene kode. Cilji vključujejo preskakovanje kode brez metode med čiščenjem smeti, postopne gradnje in boljše upravljanje pomnilnika.
- Izvršitve v času gradnje: Jezikovni konstrukti za uveljavitev imenskih prostorov, različic, odvisnosti in drugih.
- Objekti za razmestitev: Podpora za razmestitev prilagojenih izvajalnih okolij glede na posebne potrebe, na primer okolja mobilnih naprav.
Številne specifikacije in okviri modularnosti so skušali olajšati te funkcije, nekaj pa se jih je pred kratkim povzpelo na vrh predlogov za Javo 9. Pregled predlogov za modularnost Jave je spodaj.
JSR (zahteva za specifikacijo Java) 277
Trenutno neaktivna je zahteva za specifikacijo Java (JSR) 277, sistem modula Java; uvedel Sun junija 2005. Ta specifikacija je zajemala večino istih področij kot OSGi. Tako kot OSGi tudi JSR 277 opredeljuje odkrivanje, nalaganje in skladnost modulov z redko podporo za spremembe v času izvajanja in / ali preverjanje integritete.
Slabosti JSR 277 vključujejo:
- Brez dinamičnega nalaganja in razkladanja modulov / snopov
- Brez preverjanj med izvajanjem za unikatnost prostora v razredu
OSGi (pobuda Open Service Gateway)
Platforma OSGI, ki jo je novembra 1998 predstavila zveza OSGI, je najpogosteje uporabljen modularni odgovor na formalno standardno vprašanje za Javo. Trenutno ob izdaji 6 je specifikacija OSGi splošno sprejeta in se uporablja, zlasti pozno.
V bistvu je OSGi modularni sistem in servisna platforma za programski jezik Java, ki implementira celovit in dinamičen komponentni model v obliki modulov, storitev, sklopov, ki jih je mogoče uvesti itd.
Primarni sloji arhitekture OSGI so naslednji:
- Izvedbeno okolje: Okolje Java (na primer Java EE ali Java SE), v katerem se bo sveženj zagnal.
- Modul: Kjer okvir OSGi obdeluje modularne vidike svežnja. Tu se obdelujejo metapodatki o svežnju.
- Življenski krog: Tu se zgodi inicializacija, zagon in zaustavitev snopov.
- Register storitev: Kjer so v svežnjih navedene njihove storitve, ki jih lahko odkrijejo drugi svežnji.
Ena največjih pomanjkljivosti OSGi je pomanjkanje formalnega mehanizma za namestitev izvornega paketa.
JSR 291
JSR 291 je dinamični komponentni okvir za Java SE, ki temelji na OSGi in je trenutno v zaključni fazi razvoja. Ta prizadevanja se osredotočajo na vključitev OSGi v splošno Java, kot je za mobilno okolje Java naredil JSR 232.
JSR 294
JSR 294 definira sistem meta-modulov in dejansko izvedbo vtičnih modulov (različice, odvisnosti, omejitve itd.) Prenese na zunanje ponudnike. Ta specifikacija uvaja jezikovne razširitve, kot so "superpaketi" in hierarhično povezani moduli, da olajšajo modularnost. Stroga inkapsulacija in ločene enote za prevajanje so prav tako del osredotočenosti specifikacije. JSR 294 trenutno miruje.
Projektna sestavljanka
Project Jigsaw je najverjetnejši kandidat za modularnost v Javi 9. Sestavljanka želi z jezikovnimi konstrukcijami in konfiguracijami okolja definirati razširljiv modulni sistem za Java SE. Primarni cilji Jigsaw vključujejo:
- Olajšanje prilagajanja izvajalnega okolja Java SE in JDK na majhne naprave.
- Izboljšanje varnosti Java SE in JDK s prepovedjo dostopa do notranjih API-jev JDK ter z uveljavljanjem in izboljšanjem
SecurityManager.checkPackageAccessmetoda. - Izboljšanje učinkovitosti aplikacij z optimizacijo obstoječe kode in olajšanje tehnik za optimizacijo programov v prihodnosti.
- Poenostavitev razvoja aplikacij v Java SE z omogočanjem izdelave knjižnic in aplikacij iz modulov, ki jih prispevajo razvijalci, in iz modularnega JDK
- Zahteva in uveljavljanje končnega nabora omejitev različic
JEP (predlog za izboljšanje Java) 200
Predlog za izboljšanje Java 200, ustvarjen julija 2014, želi opredeliti modularno strukturo za JDK. JEP 200 temelji na ogrodju Jigsaw za lažje segmentiranje JDK v skladu z Java 8 Compact Profiles v sklope modulov, ki jih je mogoče kombinirati med prevajanjem, časom gradnje in uvajanjem. Te kombinacije modulov lahko nato uporabite kot pomanjšana okolja za izvajanje, ki so sestavljena iz modulov, skladnih s sestavljanko.
JEP 201
JEP 201 skuša nadgraditi Jigsaw za reorganizacijo izvorne kode JDK v module. Te module lahko nato kot posebne enote prevede z izboljšanim sistemom gradnje, ki uveljavi meje modulov. JEP 201 predlaga shemo prestrukturiranja izvorne kode v celotnem JDK, ki poudarja meje modulov na najvišji ravni dreves izvorne kode.
Penrose
Penrose bi upravljal interoperabilnost med Jigsaw in OSGi. Natančneje, to bi olajšalo možnost spreminjanja mikrojedr OSGi, da bi svežnji, ki se izvajajo v spremenjenem jedru, uporabljali module Jigsaw. Pri opisovanju modulov se zanaša na uporabo JSON.
Načrti za Javo 9
Java 9 je edinstvena glavna izdaja za Javo. Edinstvena je uvedba modularnih komponent in segmentov v celotnem JDK. Glavne značilnosti, ki podpirajo modularizacijo, so:
- Modularna izvorna koda: V Javi 9 bosta JRE in JDK preoblikovana v interoperabilne module. To bo omogočilo ustvarjanje razširljivih izvajalnih delov, ki jih je mogoče izvesti na majhnih napravah.
- Segmentirani predpomnilnik kode: Novi segmentirani predpomnilnik Java 9 sicer ni le modularna naprava, vendar bo sledil duhu modularizacije in užival nekatere enake prednosti. Novi predpomnilnik kode se bo pametno odločil za sestavljanje pogosto dostopnih segmentov kode v izvorno kodo in njihovo shranjevanje za optimizirano iskanje in prihodnje izvajanje. Kup bo tudi segmentiran v 3 ločene enote: koda brez metode, ki bo trajno shranjena v predpomnilniku; koda, ki ima potencialno dolg življenjski cikel (znana kot "neprofilirana koda"); in prehodno kodo (znano kot "profilirana koda").
- Izvršitve v času gradnje: Sestavni sistem bo prek JEP 201 izboljšan za prevajanje in uveljavljanje meja modulov.
- Objekti za razmestitev: V projektu Jigsaw bodo na voljo orodja, ki bodo podpirala meje, omejitve in odvisnosti modulov v času uvajanja.
Izpust Java 9 za zgodnji dostop
Čeprav natančen datum izdaje Java 9 ostaja skrivnost, lahko na Java.net prenesete izdajo za zgodnji dostop.
V zaključku
Ta članek je pregled modularnosti znotraj platforme Java, vključno z možnostmi za modularnost v Javi 9. Pojasnil sem, kako dolgoletne težave, kot je pepel na poti, prispevajo k potrebi po bolj modularni arhitekturi Java, in razpravljal o nekaterih najnovejših modularnostih funkcije, predlagane za Javo. Nato sem opisal in kontekstualiziral vse predloge ali platforme za modularnost Java, vključno z OSGi in Project Jigsaw.
Potreba po bolj modularni arhitekturi Java je jasna. Trenutni poskusi niso uspeli, čeprav se OSGi zelo približuje. Za izdajo Jave 9 bosta Project Jigsaw in OSGi glavna igralca v modularnem prostoru za Javo, Penrose pa bo morda zagotovil lepilo med njima.
To zgodbo z naslovom "Modularnost v Javi 9: skladanje s sestavljanko Project, Penrose in OSGi" je prvotno objavil JavaWorld.
