Šiame straipsnyje pateikiama pasiūlymų, specifikacijų ir platformų, skirtų „Java“ technologijai moduliuoti „Java 9“, apžvalga. Aptarsiu veiksnius, prisidedančius prie modulinės „Java“ architektūros poreikio, trumpai aprašysiu ir palyginsiu pasiūlytus sprendimus, ir pristatykite tris „Java 9“ planuojamus moduliuotumo atnaujinimus, įskaitant jų galimą poveikį „Java“ plėtrai.
Kodėl mums reikia „Java“ moduliškumo?
Moduliškumas yra bendra samprata. Programinėje įrangoje tai taikoma programos ar skaičiavimo sistemos rašymui ir įgyvendinimui kaip daugybei unikalių modulių, o ne kaip vieno monolitinio dizaino. Tada naudojama standartizuota sąsaja, leidžianti moduliams bendrauti. Programinės įrangos konstrukcijų aplinkos padalijimas į atskirus modulius padeda mums sumažinti susiejimą, optimizuoti programų kūrimą ir sumažinti sistemos sudėtingumą.
„Modularity“ suteikia programuotojams galimybę atskirai atlikti funkcionalumo testus ir lygiagrečiai vystytis tam tikro sprinto ar projekto metu. Tai padidina efektyvumą per visą programinės įrangos kūrimo gyvavimo ciklą.
Kai kurie būdingi tikro modulio atributai yra šie:
- Autonominis dislokavimo vienetas (laisva jungtis)
- Nuosekli ir unikali tapatybė (modulio ID ir versija)
- Lengvai nustatomi ir atrandami reikalavimai ir priklausomybės (standartiniai kompiliavimo laiko ir diegimo įrenginiai bei metainformacija)
- Atvira ir suprantama sąsaja (ryšio sutartis)
- Paslėpta išsami įgyvendinimo informacija (įtraukimas)
Sistemos, sukurtos efektyviai apdoroti modulius, turėtų atlikti šiuos veiksmus:
- Palaikykite moduliškumą ir priklausomybės atradimą kompiliavimo metu
- Vykdykite modulius vykdymo metu, kuris palaiko lengvą diegimą ir perkėlimą be sistemos prastovos
- Įgyvendinkite aiškų ir tvirtą vykdymo ciklą
- Suteikite patogumą lengvai registruoti ir rasti modulius
Objektyvūs, į komponentus ir paslaugas orientuoti sprendimai visi bandė įgalinti gryną moduliškumą. Kiekvienas sprendimas turi savo keistenybių rinkinį, kuris neleidžia jam pasiekti modulinio tobulumo. Trumpai apsvarstykime.
„Java“ klasės ir objektai kaip modulinės konstrukcijos
Ar objektyvus „Java“ pobūdis neatitinka moduliškumo reikalavimų? Galų gale, objektyvus programavimas naudojant „Java“ pabrėžia ir kartais įgyvendina unikalumą, duomenų kaupimą ir laisvą sujungimą. Nors šie taškai yra gera pradžia, atkreipkite dėmesį į tai keliančius moduliškumo reikalavimus nėra atitinka „Java“ į objektą orientuota sistema: tapatybė objekto lygmeniu yra nepatikima; sąsajos nėra versijomis: ir klasės nėra unikalios diegimo lygiu. Laisvas sujungimas yra geriausia praktika, tačiau ji tikrai nėra vykdoma.
Pakartotinai naudoti „Java“ klases yra sunku, kai taip lengvai netinkamai naudojama trečiųjų šalių priklausomybė. Kompiliavimo laiko priemonės, tokios kaip „Maven“, siekia pašalinti šį trūkumą. Po faktų vartojami kalbos susitarimai ir konstrukcijos, tokios kaip priklausomybės įpurškimas ir valdymo inversija, padeda kūrėjams bandyti kontroliuoti vykdymo laiką, o kartais jiems tai pavyksta, ypač jei naudojami griežtai laikantis drausmės. Deja, dėl tokios situacijos modulinės aplinkos kūrimas tenka priklausyti nuo nuosavybės pagrindų konvencijų ir konfigūracijų.
„Java“ taip pat prideda rinkinio paketų vardų sritis ir matomumą, kaip priemonę sukurti modulinius kompiliavimo ir diegimo laiko mechanizmus. Bet, kaip paaiškinsiu, šios kalbos ypatybės yra lengvai apeinamos.
Pakuotės kaip modulinis sprendimas
Paketai bando pridėti abstrakcijos lygį į „Java“ programavimo peizažą. Jie suteikia galimybę unikaliai koduoti vardų sritis ir konfigūracijos kontekstus. Deja, bet pakuočių konvencijos yra lengvai apeinamos, o tai dažnai sukelia pavojingų kompiliavimo laiko jungčių aplinką.
Šiuo metu „Java“ moduliškumo būsena (išskyrus OSGi, kurią netrukus aptarsiu) dažniausiai pasiekiama naudojant paketų vardų sritis, „JavaBeans“ konvencijas ir nuosavybės teises turinčias pagrindų konfigūracijas, tokias kaip pavasarį.
Ar JAR failai nėra pakankamai moduliniai?
JAR failai ir diegimo aplinka, kurioje jie veikia, labai patobulina daugelį kitų senų diegimo konvencijų. Tačiau JAR failai neturi savo unikalumo, išskyrus retai naudojamą versijos numerį, kuris yra paslėptas .jar manifeste. JAR failas ir pasirenkamas aprašas nėra naudojami kaip „Java“ vykdymo aplinkos moduliariojo pobūdžio susitarimai. Taigi failų klasių paketų pavadinimai ir jų dalyvavimas klasės kelyje yra vienintelės JAR struktūros dalys, suteikiančios modulio vykdymo aplinkai.
Trumpai tariant, JAR yra geras bandymas moduliuoti, tačiau jie neatitinka visų tikrai modulinės aplinkos reikalavimų. Karkasai ir platformos, pvz., „Spring“ ir „OSGi“, naudoja JAR specifikacijos modelius ir patobulinimus, kad sukurtų aplinką labai pajėgių ir modulinių sistemų kūrimui. Tačiau laikui bėgant net šios priemonės pasiduos labai apgailėtinam JAR specifikacijos šalutiniam poveikiui JAR hell!
Klasės kelias / JAR pragaras
Kai „Java“ vykdymo aplinkoje leidžiami savavališkai sudėtingi JAR įkėlimo mechanizmai, kūrėjai žino, kad jie yra klasės kelio pragaras arba JAR pragaras. Ši sąlyga gali sukelti daugybę konfigūracijų.
Pirmiausia apsvarstykite situaciją, kai „Java“ programų kūrėjas pateikia atnaujintą programos versiją ir supakuoja ją į JAR failą tokiu pačiu pavadinimu kaip ir senoji versija. „Java“ vykdymo aplinkoje nėra jokių patvirtinimo priemonių, kad būtų galima nustatyti teisingą JAR failą. Vykdymo aplinka paprasčiausiai įkelia klases iš JAR failo, kurį jis suranda pirmasis arba kuris atitinka vieną iš daugelio classpath taisyklių. Geriausiu atveju tai sukelia netikėtą elgesį.
Atsiranda dar vienas JAR pragaro atvejis, kai dvi ar daugiau programų ar procesų priklauso nuo skirtingų trečiosios šalies bibliotekos versijų. Naudojant standartines klasių įkėlimo galimybes, vykdymo metu bus pasiekiama tik viena trečiosios šalies bibliotekos versija, todėl bent vienoje programoje ar procese bus klaidų.
Visapusiška ir efektyvi „Java“ modulių sistema turėtų palengvinti kodo atskyrimą į atskirus, lengvai suprantamus ir laisvai sujungtus modulius. Priklausomybės turėtų būti aiškiai nurodytos ir griežtai vykdomos. Turi būti galimos patalpos, leidžiančios atnaujinti modulius, nedarant neigiamos įtakos kitiems moduliams. Modulinė vykdymo aplinka turėtų įgalinti konfigūracijas, būdingas konkrečiai sričiai ar vertikaliai rinkai, taip sumažinant aplinkos paleidimo laiką ir sistemos pėdsakus.
„Java“ moduliškumo sprendimai
Kartu su iki šiol paminėtomis moduliškumo savybėmis naujausios pastangos prideda dar keletą. Šios funkcijos yra skirtos našumui optimizuoti ir vykdymo laiko aplinkai išplėsti:
- Segmentuotas šaltinio kodas: Šaltinio kodas suskirstytas į atskirus, talpykloje saugomus segmentus, kurių kiekviename yra konkretaus tipo sukompiliuotas kodas. Tikslai apima netaikymo kodo praleidimą atliekant šiukšles, nuoseklų kaupimą ir geresnį atminties valdymą.
- Vykdymo laikas: Kalba sukuria vardų sritis, versijas, priklausomybes ir kt.
- Dislokavimo priemonės: Parama pritaikytų vykdymo laiko aplinkų diegimui pagal konkrečius poreikius, pavyzdžiui, mobiliųjų įrenginių aplinkai.
Daugybė moduliškumo specifikacijų ir sistemų siekė palengvinti šias savybes, o kelios pastaruoju metu iškilo į „Java 9“ pasiūlymų viršų. Žemiau pateikiama „Java“ moduliškumo pasiūlymų apžvalga.
JSR („Java“ specifikacijos užklausa) 277
Šiuo metu neveikia „Java Specification Request“ (JSR) 277, „Java Module System“; „Sun“ pristatė 2005 m. birželio mėn. Ši specifikacija apėmė daugumą tų pačių sričių kaip ir OSGi. Kaip ir OSGi, JSR 277 taip pat apibrėžia modulių atradimą, įkėlimą ir nuoseklumą, retai palaikydamas vykdymo laiko modifikacijas ir (arba) vientisumo tikrinimą.
JSR 277 trūkumai yra šie:
- Nėra dinamiško modulių / paketų pakrovimo ir iškrovimo
- Nėra vykdymo laiko tikrinant klasės ir vietos unikalumą
OSGi („Open Service Gateway Initiative“)
OSGI aljansas, pristatytas 1998 m. Lapkričio mėn., OSGI platforma yra plačiausiai naudojamas modularumo atsakymas į oficialų standartinį „Java“ klausimą. Šiuo metu 6 leidime OSGi specifikacija yra plačiai priimta ir naudojama, ypač vėlyvojo.
Iš esmės „OSGi“ yra modulinė sistema ir „Java“ programavimo kalbos paslaugų platforma, įgyvendinanti išsamų ir dinamišką komponentų modelį modulių, paslaugų, diegiamų paketų ir kt. Pavidalu.
Pagrindiniai OSGI architektūros sluoksniai yra šie:
- Vykdymo aplinka: „Java“ aplinka (pvz., „Java EE“ arba „Java SE“), kurioje bus vykdomas ryšys.
- Modulis: Kai OSGi sistema apdoroja rinkinio modulinius aspektus. Čia apdorojami grupiniai metaduomenys.
- Gyvenimo ciklas: Čia vyksta grupių inicijavimas, paleidimas ir sustabdymas.
- Paslaugų registras: Kur paketuose pateikiamos jų paslaugos, kurias gali rasti kiti ryšuliai.
Vienas didžiausių OSGi trūkumų yra oficialaus paketo diegimo mechanizmo nebuvimas.
JSR 291
„JSR 291“ yra dinaminė „Java SE“ komponentų sistema, pagrįsta OSGi, šiuo metu yra paskutiniame kūrimo etape. Šios pastangos sutelktos į OSGi įtraukimą į pagrindinę „Java“, kaip tai padarė „Java“ mobiliajai aplinkai JSR 232.
JSR 294
JSR 294 apibrėžia metamodulių sistemą ir deleguoja išorinių paslaugų teikėjų tikrąjį įskiepių modulių (versijų, priklausomybių, apribojimų ir kt.) Įkūnijimą. Šioje specifikacijoje pateikiami kalbos plėtiniai, tokie kaip „superpaketai“ ir su hierarchija susiję moduliai, kad būtų lengviau moduliuoti. Griežtas inkapsuliavimas ir aiškūs kompiliavimo vienetai taip pat yra spec. Dėmesio centre. JSR 294 šiuo metu neveikia.
Projektas Dėlionė
Projektas „Jigsaw“ yra greičiausias kandidatas į „Java 9“ moduliškumą. „Jigsaw“ siekia naudoti kalbos konstrukcijas ir aplinkos konfigūracijas, kad apibrėžtų „Java SE“ keičiamo dydžio modulių sistemą. Pagrindiniai „Jigsaw“ tikslai:
- Tai leidžia labai lengvai išplėsti „Java SE“ vykdymo laiką ir JDK iki mažų įrenginių.
- Gerinti „Java SE“ ir JDK saugumą uždraudus prieigą prie vidinių „JDK“ API ir užtikrinant bei tobulinant
„SecurityManager.checkPackageAccess“metodas. - Programos našumo gerinimas optimizuojant esamą kodą ir palengvinant perspektyvias programos optimizavimo technikas.
- „Java SE“ programų kūrimo supaprastinimas, leidžiant kurti bibliotekas ir programas iš kūrėjų įvestų modulių ir modulinio JDK
- Reikalauti ir vykdyti ribotą versijos apribojimų rinkinį
JEP („Java“ patobulinimo pasiūlymas) 200
2014 m. Liepos mėn. Sukurtu „Java Enhancement 200“ pasiūlymu siekiama apibrėžti JDK modulinę struktūrą. „JEP 200“ remiasi „Jigsaw“ sistema, kad būtų lengviau segmentuoti JDK, remiantis „Java 8 Compact Profiles“, į modulių rinkinius, kuriuos galima sujungti kompiliavimo, kūrimo ir diegimo metu. Šie modulių deriniai gali būti diegiami kaip sumažintos vykdymo aplinkos aplinkos, sudarytos iš „Jigsaw“ suderinamų modulių.
JEP 201
JEP 201 siekia sukurti „Jigsaw“, kad JDK šaltinio kodas būtų pertvarkytas į modulius. Šie moduliai gali būti sudaryti kaip atskiri vienetai pagal patobulintą kaupimo sistemą, kuri vykdo modulio ribas. JEP 201 siūlo šaltinio kodo restruktūrizavimo schemą visoje JDK, kurioje akcentuojamos modulio ribos viršutiniame šaltinio kodų medžių lygyje.
Penrose
„Penrose“ valdytų „Jigsaw“ ir „OSGi“ sąveiką. Tiksliau, tai palengvintų galimybę modifikuoti „OSGi“ mikrobranduolius, kad modifikuotame branduolyje veikiantys rinkiniai galėtų naudoti „Jigsaw“ modulius. Jis remiasi JSON naudojimu aprašant modulius.
„Java 9“ planai
„Java 9“ yra unikalus pagrindinis „Java“ leidimas. Išskirtinis yra modulinių komponentų ir segmentų pristatymas visoje JDK. Pagrindinės funkcijos, palaikančios moduliavimą, yra šios:
- Modulinis šaltinio kodas: „Java 9“ versijoje JRE ir JDK bus pertvarkyti į sąveikius modulius. Tai leis sukurti keičiamo dydžio vykdymo laiką, kurį galima vykdyti mažuose įrenginiuose.
- Segmentuota kodo talpykla: Nors tai nėra griežtai modulinė įranga, naujoji „Java 9“ segmentinė kodo talpykla vadovausis moduliavimo dvasia ir naudosis tais pačiais pranašumais. Nauja kodo talpykla priims protingus sprendimus, jei norite surinkti dažnai pasiekiamus kodo segmentus į gimtąjį kodą ir juos saugoti, kad būtų galima optimizuoti paiešką ir vykdyti ateityje. Krūva taip pat bus suskirstyta į 3 atskirus vienetus: ne metodo kodas, kuris bus nuolat saugomas talpykloje; kodas, kurio gyvavimo ciklas gali būti ilgas (vadinamas „neprofiliuotu kodu“); ir trumpalaikis kodas (žinomas kaip „profiliuotas kodas“).
- Vykdymo laikas: Sukūrimo sistema bus patobulinta per JEP 201, kad būtų sudarytos ir užtikrintos modulio ribos.
- Dislokavimo priemonės: „Jigsaw“ projekte bus pateikti įrankiai, kurie palaikys modulio ribas, apribojimus ir priklausomybes diegimo metu.
„Java 9“ ankstyvosios prieigos leidimas
Nors tiksli „Java 9“ išleidimo data tebėra paslaptis, išankstinės prieigos leidimą galite atsisiųsti iš „Java.net“.
Apibendrinant
Šis straipsnis apžvelgė „Java“ platformos moduliškumą, įskaitant „Java 9“ moduliškumo perspektyvas. Aš paaiškinau, kaip ilgai trunkantys klausimai, pvz., „Classpath hell“, prisideda prie modulinės „Java“ architektūros poreikio, ir aptariau kai kuriuos naujausius naujus moduliškumus. siūlomos „Java“ funkcijos. Tada aprašiau ir kontekstualizavau kiekvieną „Java“ moduliškumo pasiūlymą ar platformą, įskaitant „OSGi“ ir „Project Jigsaw“.
Modulinės „Java“ architektūros poreikis yra aiškus. Dabartiniai bandymai nesėkmingi, nors OSGi yra labai arti. „Java 9“ leidime „Project Jigsaw“ ir „OSGi“ bus pagrindiniai „Java“ modulinės erdvės žaidėjai, o Penrose'as gali pateikti klijus tarp jų.
Šią istoriją „Modularity in Java 9: Stacking with Project Jigsaw, Penrose and OSGi“ iš pradžių paskelbė „JavaWorld“.
