Modularnost u Javi 9: slaganje s projektom Jigsaw, Penrose i OSGi

Ovaj članak daje pregled prijedloga, specifikacija i platformi čiji je cilj Java tehnologiju učiniti modularnijom u Javi 9. Razmotrit ću čimbenike koji pridonose potrebi za modularnijom Java arhitekturom, ukratko ću opisati i usporediti predložena rješenja, i predstaviti tri ažuriranja modularnosti planirana za Javu 9, uključujući njihov potencijalni utjecaj na razvoj Jave.

Zašto nam treba Java modularnost?

Modularnost je opći pojam. U softveru se odnosi na pisanje i implementaciju programa ili računalnog sustava kao više jedinstvenih modula, a ne kao jedan, monolitni dizajn. Tada se koristi standardizirano sučelje kako bi se modulima omogućila komunikacija. Dijeljenje okoline softverskih konstrukcija na zasebne module pomaže nam minimizirati sprezanje, optimizirati razvoj aplikacija i smanjiti složenost sustava.

Modularnost omogućuje programerima da izolirano testiraju funkcionalnost i uključe se u paralelne razvojne napore tijekom određenog sprinta ili projekta. To povećava učinkovitost tijekom cijelog životnog ciklusa razvoja softvera.

Neki karakteristični atributi izvornog modula su:

  • Nezavisna jedinica za raspoređivanje (labava spojnica)
  • Dosljedan i jedinstven identitet (ID modula i verzija)
  • Lako identificirani i otkriveni zahtjevi i ovisnosti (standardni uređaji za vrijeme prevođenja i postavljanja i meta-informacije)
  • Otvoreno i razumljivo sučelje (ugovor o komunikaciji)
  • Skriveni detalji implementacije (enkapsulacija)

Sustavi koji su izgrađeni za učinkovitu obradu modula trebali bi učiniti sljedeće:

  • Podržati modularnost i otkrivanje ovisnosti u vrijeme prevođenja
  • Izvršite module u runtime okruženju koje podržava lako postavljanje i preraspodjelu bez zastoja sustava
  • Provedite životni ciklus izvršenja koji je jasan i robustan
  • Omogućite olakšano registriranje i otkrivanje modula

Objektno orijentirana, komponentna i uslužno orijentirana rješenja pokušala su omogućiti čistu modularnost. Svako rješenje ima svoj set hirovitosti koji ga sprječavaju u postizanju modularnog savršenstva. Kratko razmotrimo.

Java klase i objekti kao modularni konstrukti

Ne ispunjava li objektno orijentirana priroda Java zahtjeve modularnosti? Napokon, objektno orijentirano programiranje s Javom naglašava i ponekad nameće jedinstvenost, inkapsulaciju podataka i labavo spajanje. Iako su ove točke dobar početak, primijetite zahtjeve za modularnost koje Java-ov objektno orijentirani okvir ne ispunjava: identitet na razini objekta je nepouzdan; sučelja nisu verzijska: a klase nisu jedinstvene na razini implementacije. Labavo spajanje najbolja je praksa, ali sigurno se ne provodi.

Ponovna upotreba klasa u Javi je teška kad se ovisnosti trećih strana tako lako zloupotrijebe. Alati kompilacije poput Mavena nastoje riješiti ovaj nedostatak. Jezične konvencije i konstrukcije kao što su injekcije ovisnosti i inverzija kontrole pomažu programerima u našim pokušajima da kontroliraju runtime okruženje, a ponekad i uspiju, pogotovo ako se koriste uz strogu disciplinu. Nažalost, ova situacija ostavlja posao stvaranja modularnog okruženja do vlasničkih okvirnih konvencija i konfiguracija.

Java također dodaje prostor imenskih prostora paketa i vidljivost opsega miksu kao sredstvo za stvaranje modularnih mehanizama vremena kompajliranja i vremena implementacije. Ali ove jezične značajke lako se zaobilaze, kao što ću objasniti.

Paketi kao modularno rješenje

Paketi pokušavaju dodati razinu apstrakcije u programski pejzaž Java. Omogućuju jedinstvene prostore kodiranja imena i konfiguracijski kontekst. Nažalost, ipak se konvencije paketa lako zaobilaze, što često dovodi do okruženja opasnih spojnica tijekom kompajliranja.

Trenutno se stanje modularnosti u Javi (osim OSGi-a, o čemu ću uskoro raspravljati) najčešće postiže pomoću prostora imena paketa, konvencija JavaBeans i vlasničkih konfiguracija okvira poput onih pronađenih u proljeće.

Nisu li JAR datoteke dovoljno modularne?

JAR datoteke i okruženje za implementaciju u kojem rade uvelike poboljšavaju mnoge konvencije o raspoređivanju koje su inače dostupne. No JAR datoteke nemaju suštinsku jedinstvenost, osim rijetko korištenog broja verzije, koji je skriven u .jar manifestu. JAR datoteka i opcijski manifest ne koriste se kao konvencije modularnosti unutar Java runtime okruženja. Dakle, nazivi paketa klasa u datoteci i njihovo sudjelovanje u putu predavanja jedini su dijelovi JAR strukture koji pridaju modularnost runtime okruženju.

Ukratko, JAR-ovi su dobar pokušaj modularizacije, ali ne ispunjavaju sve zahtjeve za istinski modularno okruženje. Okviri i platforme poput Springa i OSGi-a koriste obrasce i poboljšanja JAR specifikacije kako bi osigurali okruženja za izgradnju vrlo sposobnih i modularnih sustava. Međutim, s vremenom će čak i ovi alati podleći vrlo nesretnoj nuspojavi JAR specifikacije JAR specifikacije!

Klasna staza / JAR pakao

Kada Java runtime okruženje dopušta proizvoljno složene mehanizme učitavanja JAR, programeri znaju da se nalaze u paklu razreda ili JAR paklu . Brojne konfiguracije mogu dovesti do ovog stanja.

Prvo razmotrite situaciju kada programer Java programa pruža ažuriranu verziju aplikacije i pakira je u JAR datoteku s istim imenom kao i stara verzija. Java runtime okruženje ne pruža mogućnosti provjere valjanosti za određivanje ispravne JAR datoteke. Runtime okruženje jednostavno će učitati klase iz JAR datoteke koju prvo pronađe ili koja zadovoljava jedno od mnogih pravila o putovima razreda. To u najboljem slučaju dovodi do neočekivanog ponašanja.

Još jedan slučaj JAR pakla nastaje kada dvije ili više aplikacija ili procesa ovise o različitim verzijama biblioteke treće strane. Korištenjem standardnih mogućnosti učitavanja klasa, samo će jedna verzija biblioteke treće strane biti dostupna tijekom izvođenja, što dovodi do pogrešaka u barem jednoj aplikaciji ili procesu.

Potpuno opremljen i učinkovit sustav Java modula trebao bi olakšati razdvajanje koda na zasebne, lako razumljive i slabo povezane module. Ovisnosti bi trebale biti jasno određene i strogo se provoditi. Trebali bi biti dostupni uređaji koji omogućuju nadogradnju modula bez negativnog utjecaja na druge module. Modularno vrijeme izvođenja trebalo bi omogućiti konfiguracije specifične za određenu domenu ili okomito tržište, smanjujući tako vrijeme pokretanja i trag sustava u okruženju.

Rješenja modularnosti za Javu

Uz do sada spomenute značajke modularnosti, nedavni napori dodaju još nekoliko. Sljedeće su značajke namijenjene optimizaciji izvedbe i omogućavanju proširenja okruženja izvođenja:

  • Segmentirani izvorni kod : Izvorni kod odvojen u zasebne, predmemorirane segmente, od kojih svaki sadrži određenu vrstu prevedenog koda. Ciljevi uključuju preskakanje koda bez metode tijekom čišćenja smeća, inkrementalne izrade i bolje upravljanje memorijom.
  • Provedbe vremena izgradnje: jezični konstrukti za provođenje prostora imena, izrade verzija, ovisnosti i drugih.
  • Postrojenja za postavljanje: Podrška za razmještanje skaliranih runtime okruženja u skladu sa specifičnim potrebama, poput onih u okruženju mobilnih uređaja.

Brojne specifikacije i okviri modularnosti nastoje olakšati ove značajke, a nekoliko se nedavno popelo na vrh prijedloga za Javu 9. Pregled prijedloga modularnosti Jave nalazi se u nastavku.

JSR (Zahtjev za specifikaciju Java) 277

Trenutno je neaktivan zahtjev za specifikacijom Java (JSR) 277, sustav Java modula; uveo Sun u lipnju 2005. Ova specifikacija pokrivala je većinu istih područja kao i OSGi. Poput OSGi, JSR 277 također definira otkrivanje, učitavanje i dosljednost modula, s oskudnom podrškom za runtime modifikacije i / ili provjeru integriteta.

Nedostaci JSR 277 uključuju:

  • Nema dinamičkog utovara i istovara modula / snopova
  • Nema provjeravanja jedinstvenosti prostora klase tijekom izvođenja

OSGi (Open Service Gateway Initiative)

Predstavljen od strane OSGI Alliance u studenom 1998. godine, OSGI platforma je najčešće korišteni modularni odgovor na formalno standardno pitanje za Javu. Trenutno u izdanju 6, OSGi specifikacija je široko prihvaćena i koristi se, posebno kasno.

U osnovi, OSGi je modularni sustav i servisna platforma za programski jezik Java koji implementira cjelovit i dinamičan model komponenata u obliku modula, usluga, raspoloživih snopova itd.

Primarni slojevi OSGI arhitekture su kako slijedi:

  • Izvršno okruženje : Java okruženje (na primjer, Java EE ili Java SE) pod kojim će se paket izvoditi.
  • Modul : Gdje OSGi okvir obrađuje modularne aspekte snopa. Ovdje se obrađuju metapodaci snopa.
  • Životni ciklus : ovdje se događa inicijalizacija, pokretanje i zaustavljanje snopova.
  • Registar usluga : tamo gdje svežnji navode svoje usluge za otkrivanje drugih snopova.

Jedan od najvećih nedostataka OSGi-a je nedostatak formalnog mehanizma za instalaciju izvornog paketa.

JSR 291

JSR 291 je dinamički komponentni okvir za Java SE koji se temelji na OSGi-u i trenutno je u završnoj fazi razvoja. Ovaj se napor usredotočuje na uvođenje OSGi-a u glavnu Javu, kao što je to učinio za Java mobilno okruženje JSR 232.

JSR 294

JSR 294 definira sustav meta-modula i delegira stvarno utjelovljenje priključnih modula (verzije, ovisnosti, ograničenja, itd.) Vanjskim dobavljačima. Ova specifikacija uvodi jezična proširenja, kao što su "superpaketi" i hijerarhijski povezani moduli, kako bi se olakšala modularnost. Stroga enkapsulacija i zasebne jedinice kompilacije također su dio fokusa specifikacije. JSR 294 trenutno miruje.

Jigsaw projekta

Project Jigsaw je najizgledniji kandidat za modularnost u Javi 9. Jigsaw nastoji koristiti jezične konstrukcije i konfiguracije okruženja za definiranje skalabilnog modularnog sustava za Java SE. Primarni ciljevi Jigsawa uključuju:

  • Olakšavajući prilagodbu vremena izvođenja Java SE i JDK na male uređaje.
  • Poboljšanje sigurnosti Java SE i JDK zabranom pristupa internim JDK API-ima i provođenjem i poboljšanjem SecurityManager.checkPackageAccessmetode.
  • Poboljšanje izvedbe aplikacija optimizacijom postojećeg koda i olakšavanje tehnika optimizacije programa koji unaprijed gleda.
  • Pojednostavljivanje razvoja aplikacija u Java SE omogućavanjem izrade knjižnica i aplikacija od modula koje su pridonijeli programeri i od modularnog JDK
  • Zahtjev i primjena konačnog skupa ograničenja verzije

JEP (Prijedlog za poboljšanje Jave) 200

Prijedlog za poboljšanje Java 200, stvoren u srpnju 2014., nastoji definirati modularnu strukturu za JDK. JEP 200 nadovezuje se na okvir Jigsaw kako bi olakšao segmentiranje JDK, prema Java 8 Compact Profiles, u skupove modula koji se mogu kombinirati u vrijeme sastavljanja, vremena izrade i vremena primjene. Te se kombinacije modula zatim mogu rasporediti kao smanjeno vrijeme izvođenja koja se sastoje od Jigsaw-usklađenih modula.

JEP 201

JEP 201 nastoji nadograditi Jigsaw za reorganizaciju JDK izvornog koda u module. Ti se moduli tada mogu kompilirati kao zasebne jedinice pomoću poboljšanog sustava gradnje koji provodi granice modula. JEP 201 predlaže shemu restrukturiranja izvornog koda u cijelom JDK koja naglašava granice modula na najvišoj razini stabala izvornog koda.

Penrose

Penrose bi upravljao interoperabilnošću između Jigsawa i OSGi-a. Točnije, olakšalo bi mogućnost modifikacije OSGi mikro-jezgri kako bi snopovi koji se izvode u modificiranom jezgru koristili Jigsaw module. Oslanja se na upotrebu JSON-a za opisivanje modula.

Planovi za Javu 9

Java 9 jedinstveno je glavno izdanje za Javu. Ono što ga čini jedinstvenim je uvođenje modularnih komponenata i segmenata kroz čitav JDK . Primarne značajke koje podržavaju modularizaciju su:

  • Modularni izvorni kod : U Javi 9 JRE i JDK bit će reorganizirani u interoperabilne module. To će omogućiti stvaranje skalabilnih runtimeova koji se mogu izvršiti na malim uređajima.
  • Segmentirana predmemorija koda : Iako nije strogo modularna oprema, nova segmentirana predmemorija koda Java 9 slijedit će duh modularizacije i uživati ​​u istim prednostima. Nova će predmemorija koda donijeti inteligentne odluke o kompajliranju često pristupanih segmenata koda u izvorni kôd i pohraniti ih za optimizirano pretraživanje i buduće izvršavanje. Hrpa će također biti segmentirana u 3 zasebne cjeline: kod bez metode koji će se trajno pohraniti u predmemoriju; kôd koji ima potencijalno dug životni ciklus (poznat kao "neprofilirani kôd"); i kod koji je prijelazan (poznat kao "profilirani kôd").
  • Provedbe vremena gradnje: Sustav izgradnje bit će poboljšan, putem JEP 201, radi sastavljanja i provođenja granica modula.
  • Postrojenja za postavljanje : U okviru Jigsaw projekta pružit će se alati koji će podržavati granice modula, ograničenja i ovisnosti u vrijeme implementacije.

Izdanje Java 9 za rani pristup

Iako točan datum izlaska Java 9 ostaje tajna, možete preuzeti izdanje za rani pristup na Java.net.

U zaključku

Ovaj je članak pregled modularnosti unutar Java platforme, uključujući izglede za modularnost u Javi 9. Objasnio sam kako dugotrajni problemi poput pakla klase doprinose potrebi za modularnijom Java arhitekturom i razgovarao o nekim od najnovijih novih modularnosti značajke predložene za Javu. Zatim sam opisao i kontekstualizirao svaki od prijedloga ili platformi za modularnost Java, uključujući OSGi i Project Jigsaw.

Jasna je potreba za modularnijom Java arhitekturom. Trenutni pokušaji nisu uspjeli, iako se OSGi vrlo približava. Za izdanje Java 9 Project Jigsaw i OSGi bit će glavni igrači u modularnom prostoru za Javu, a Penrose će možda osigurati ljepilo između njih.

Ovu je priču "Modularnost u Javi 9: slaganje s projektom Jigsaw, Penrose i OSGi" izvorno objavio JavaWorld.