Tässä artikkelissa on yleiskatsaus ehdotuksista, spesifikaatioista ja alustoista, joiden tarkoituksena on tehdä Java-tekniikasta modulaarisempaa Java 9: ssä. Keskustelen tekijöistä, jotka vaikuttavat modulaarisemman Java-arkkitehtuurin tarpeeseen, kuvaan lyhyesti ja vertaan ehdotettuja ratkaisuja, ja esitellä Java 9: lle suunnitellut kolme modulaarisuuspäivitystä, mukaan lukien niiden mahdolliset vaikutukset Java-kehitykseen.
Miksi tarvitsemme Java-modulaarisuutta?
Modulaarisuus on yleinen käsite. Ohjelmistossa sitä sovelletaan ohjelman tai tietojenkäsittelyjärjestelmän kirjoittamiseen ja toteuttamiseen useina ainutlaatuisina moduuleina, eikä yhtenä, monoliittisena suunnitteluna. Sitten käytetään standardoitua rajapintaa, jotta moduulit voivat kommunikoida. Ohjelmistorakenteiden ympäristön jakaminen erillisiin moduuleihin auttaa minimoimaan kytkennän, optimoimaan sovelluskehityksen ja vähentämään järjestelmän monimutkaisuutta.
Modulaarisuus antaa ohjelmoijille mahdollisuuden tehdä toimintatestejä erillään ja harjoittaa rinnakkaisia kehitystoimia tietyssä sprintissä tai projektissa. Tämä lisää tehokkuutta koko ohjelmistokehityksen elinkaaren ajan.
Joitakin aidon moduulin tunnusmerkkejä ovat:
- Itsenäinen käyttöönottoyksikkö (löysä kytkentä)
- Yhtenäinen ja yksilöllinen identiteetti (moduulin tunnus ja versio)
- Helposti tunnistettavat ja löydettävät vaatimukset ja riippuvuudet (vakioidut käännös- ja käyttöönottotilat sekä metatiedot)
- Avoin ja ymmärrettävä käyttöliittymä (viestintäsopimus)
- Piilotetut toteutustiedot (kapselointi)
Järjestelmien, jotka on rakennettu käsittelemään moduulit tehokkaasti, tulisi toimia seuraavasti:
- Tukee modulaarisuutta ja riippuvuuden löytämistä kokoamisaikana
- Suorita moduulit ajonaikaisessa ympäristössä, joka tukee helppoa käyttöönottoa ja uudelleensijoittamista ilman järjestelmän seisokkeja
- Toteuta toteutuksen elinkaari, joka on selkeä ja kestävä
- Tarjoa tilat moduulien helpolle rekisteröinnille ja löytämiselle
Objekti-, komponentti- ja palvelukeskeiset ratkaisut ovat kaikki yrittäneet mahdollistaa puhtaan modulaarisuuden. Jokaisella ratkaisulla on omat erikoisuutensa, jotka estävät sitä saavuttamasta modulaarista täydellisyyttä. Tarkastellaan lyhyesti.
Java-luokat ja objektit modulaarisina rakenteina
Eikö Java ole olio-orientoitu, täytä modulaarisuuden vaatimukset? Loppujen lopuksi olio-ohjelmointi Java-ohjelmalla korostaa ja toisinaan vahvistaa ainutlaatuisuutta, tietojen kapselointia ja löysää kytkentää. Vaikka nämä kohdat ovat hyvä alku, huomaa modulaarisuusvaatimukset eivät ole täyttää Java: n olio-kehys: identiteetti objektitasolla on epäluotettava; rajapintoja ei ole versioitu: ja luokat eivät ole ainutlaatuisia käyttöönottotasolla. Löysä kytkentä on paras käytäntö, mutta sitä ei varmasti noudateta.
Luokkien uudelleenkäyttö Java-tilassa on vaikeaa, kun kolmannen osapuolen riippuvuuksia käytetään niin helposti väärin. Mavenin kaltaiset kääntöaikaiset työkalut pyrkivät korjaamaan tämän puutteen. Tosiasialliset kielenkäytännöt ja -rakenteet, kuten riippuvuusinjektio ja hallinnan kääntäminen, auttavat kehittäjiä yrityksissämme hallita ajonaikaisia ympäristöjä, ja joskus ne onnistuvat, varsinkin jos niitä käytetään tiukasti. Valitettavasti tämä tilanne jättää modulaarisen ympäristön luomisen tehtävän omien kehyskäytäntöjen ja kokoonpanojen mukaan.
Java lisää myös sekoitukseen pakettien nimitilat ja laajuuden näkyvyyden keinona luoda modulaarisia käännösaikaa ja käyttöönottoaikamekanismeja. Mutta nämä kieliominaisuudet ohitetaan helposti, kuten selitän.
Paketit modulaarisena ratkaisuna
Paketit yrittävät lisätä abstraktiotason Java-ohjelmointimaisemaan. Ne tarjoavat tilat ainutlaatuisille koodaaville nimitiloille ja kokoonpanokonteksteille. Valitettavasti pakettikäytäntöjä on kuitenkin helppo kiertää, mikä johtaa usein vaarallisten kokoamisajan kytkentöjen ympäristöön.
Javan modulaarisuuden tila tällä hetkellä (lukuun ottamatta OSGiä, josta keskustelen pian) saavutetaan useimmiten käyttämällä pakettien nimitiloja, JavaBeans-käytäntöjä ja omia kehyskokoonpanoja, kuten Springissä.
Eivätkö JAR-tiedostot ole riittävän modulaarisia?
JAR-tiedostot ja asennusympäristö, jossa ne toimivat, parantavat huomattavasti muuten saatavilla olevia vanhoja käyttöönottokäytäntöjä. Mutta JAR-tiedostoilla ei ole sisäistä ainutlaatuisuutta lukuun ottamatta harvoin käytettyä versionumeroa, joka on piilotettu .jar-manifestissa. JAR-tiedostoa ja valinnaista luetteloa ei käytetä modulaarisuussopimuksina Java-ajonaikaisessa ympäristössä. Joten tiedostossa olevien luokkien pakettien nimet ja niiden osallistuminen luokkatielle ovat JAR-rakenteen ainoat osat, jotka antavat modulaarisuutta ajonaikaiselle ympäristölle.
Lyhyesti sanottuna JAR: t ovat hyvä yritys modularisoida, mutta ne eivät täytä kaikkia todella modulaarisen ympäristön vaatimuksia. Kehykset ja alustat, kuten Spring ja OSGi, käyttävät malleja ja parannuksia JAR-määrityksiin tarjotakseen ympäristöjä erittäin kykenevien ja modulaaristen järjestelmien rakentamiseen. Ajan myötä nämäkin työkalut perääntyvät JAR-spesifikaation JAR hell! Erittäin valitettavaan sivuvaikutukseen!
Luokkatie / JAR helvetti
Kun Java-ajonaikainen ympäristö sallii mielivaltaisesti monimutkaiset JAR-latausmekanismit, kehittäjät tietävät, että ne ovat luokkatien helvetti tai JAR helvetti. Useat kokoonpanot voivat johtaa tähän tilaan.
Harkitse ensin tilannetta, jossa Java-sovelluskehittäjä tarjoaa päivitetyn version sovelluksesta ja on pakannut sen JAR-tiedostoon, jolla on täsmälleen sama nimi kuin vanhalla versiolla. Java-ajonaikaisessa ympäristössä ei ole vahvistustoimintoja oikean JAR-tiedoston määrittämiseksi. Ajonaikainen ympäristö yksinkertaisesti lataa luokat JAR-tiedostosta, jonka se löytää ensin tai joka täyttää yhden monista classpath-säännöistä. Tämä johtaa parhaimmillaan odottamattomaan käyttäytymiseen.
Toinen JAR-helvetti esiintyy, kun kaksi tai useampi sovellus tai prosessi riippuu kolmannen osapuolen kirjaston eri versioista. Vakioluokan latausominaisuuksien avulla vain yksi kolmannen osapuolen kirjaston versio on käytettävissä ajon aikana, mikä johtaa virheisiin ainakin yhdessä sovelluksessa tai prosessissa.
Täysin varustellun ja tehokkaan Java-moduulijärjestelmän tulisi helpottaa koodin erottamista erillisiksi, helposti ymmärrettäviksi ja löyhästi kytketyiksi moduuleiksi. Riippuvuudet olisi määriteltävä selkeästi ja pantava tiukasti täytäntöön. Olisi oltava käytettävissä tiloja, jotka mahdollistavat moduulien päivittämisen vaikuttamatta kielteisesti muihin moduuleihin. Modulaarisen ajonaikaisen ympäristön tulisi mahdollistaa kokoonpanot, jotka ovat ominaisia tietylle toimialueelle tai vertikaalimarkkinoille, mikä vähentää ympäristön käynnistymisaikaa ja järjestelmän jalanjälkeä.
Java-modulaarisuusratkaisut
Tähän mennessä mainittujen modulaarisuusominaisuuksien lisäksi viimeisimmät ponnistelut lisäävät vielä muutamia. Seuraavat ominaisuudet on tarkoitettu optimoimaan suorituskyky ja mahdollistamaan ajonaikaisen ympäristön laajentaminen:
- Segmentoitu lähdekoodi: Lähdekoodi erotettuna erillisiksi välimuistissa oleviksi segmenteiksi, joista kukin sisältää tietyn tyyppisen käännetyn koodin. Tavoitteisiin kuuluu muun kuin menetelmän koodin ohittaminen roskapuhdistuksen aikana, inkrementaaliset koontiversiot ja parempi muistinhallinta.
- Rakennuksen aikaiset täytäntöönpanotoimet: Kieli rakentaa nimitiloja, versioita, riippuvuuksia ja muita.
- Käyttöönottotilat: Tuki skaalattujen ajo-ympäristöjen käyttöönotolle erityistarpeiden mukaan, kuten mobiililaiteympäristön.
Useat modulaarisuusspesifikaatiot ja kehykset ovat pyrkineet helpottamaan näitä ominaisuuksia, ja muutama on noussut viime aikoina kärkeen Java 9 -ehdotuksissa. Alla on yleiskatsaus Java-modulaarisuusehdotuksiin.
JSR (Java-määrityspyyntö) 277
Tällä hetkellä ei-aktiivinen on Java Specification Request (JSR) 277, Java Module System; Sun esitteli kesäkuussa 2005. Tämä eritelmä kattoi suurimman osan samoista alueista kuin OSGi. Kuten OSGi, JSR 277 määrittelee myös moduulien etsinnän, lataamisen ja yhdenmukaisuuden, ja niukasti tuetaan ajonaikaisia muutoksia ja / tai eheyden tarkistamista.
JSR 277: n haittoja ovat:
- Ei moduulien / nippujen dynaamista lataamista ja purkamista
- Ei ajonaikaisia tarkistuksia luokkatilan ainutlaatuisuuden suhteen
OSGi (Open Service Gateway Initiative)
OSGI-liittouma esitteli marraskuussa 1998 OSGI-alustan, joka on yleisimmin käytetty modulaarisuusvastaus Java-muodolliseen vakiokysymykseen. Tällä hetkellä julkaisussa 6 OSGi-spesifikaatio on laajalti hyväksytty ja käytetty, erityisesti myöhässä.
Pohjimmiltaan OSGi on modulaarinen järjestelmä ja Java-ohjelmointikielen palvelualusta, joka toteuttaa täydellisen ja dynaamisen komponenttimallin moduulien, palveluiden, käyttöönotettavien nippujen ja niin edelleen.
OSGI-arkkitehtuurin ensisijaiset kerrokset ovat seuraavat:
- Suoritusympäristö: Java-ympäristö (esimerkiksi Java EE tai Java SE), jossa paketti suoritetaan.
- Moduuli: Jos OSGi-kehys käsittelee nipun modulaariset näkökohdat. Nipun metatiedot käsitellään täällä.
- Elinkaari: Nippujen alustaminen, käynnistäminen ja lopettaminen tapahtuu täällä.
- Palvelurekisteri: Missä niput luetelevat palvelunsa muiden nippujen löytämiseksi.
Yksi suurimmista OSGi-haitoista on muodollisen mekanismin puuttuminen natiivipakettien asennusta varten.
JSR 291
JSR 291 on Java SE: n dynaaminen komponenttikehys, joka perustuu OSGiin ja on tällä hetkellä viimeisessä kehitysvaiheessa. Tämä ponnistelu keskittyy ottamaan OSGi osaksi Java-valtavirtaa, kuten JSR 232 teki Java-mobiiliympäristölle.
JSR 294
JSR 294 määrittelee metamoduulijärjestelmän ja delegoi liitettävien moduulien (versiot, riippuvuudet, rajoitukset jne.) Varsinaisen suoritusmuodon ulkopuolisille toimittajille. Tämä eritelmä esittelee kielilaajennuksia, kuten "superpaketit" ja hierarkkisesti liittyvät moduulit modulaarisuuden helpottamiseksi. Tiukka kapselointi ja erilliset kokoamisyksiköt ovat myös osa spesifikaation painopistettä. JSR 294 on tällä hetkellä lepotilassa.
Projekti palapeli
Project Jigsaw on todennäköisin modulaarisuuden ehdokas Java 9: ssä. Jigsaw pyrkii käyttämään kielirakenteita ja ympäristökokoonpanoja määrittelemään skaalautuvan moduulijärjestelmän Java SE: lle. Palapelin ensisijaisia tavoitteita ovat:
- Java SE: n ajonaikaisen ja JDK: n pienentäminen pieniin laitteisiin on erittäin helppoa.
- Parannetaan Java SE: n ja JDK: n turvallisuutta kieltämällä pääsy sisäisiin JDK-sovellusliittymiin ja valvomalla ja parantamalla
SecurityManager.checkPackageAccessmenetelmä. - Sovelluksen suorituskyvyn parantaminen optimoimalla olemassa olevaa koodia ja helpottamalla ohjelmien etukäteen optimointia.
- Yksinkertaistetaan Java SE: n sovelluskehitystä mahdollistamalla kirjastojen ja sovellusten rakentaminen kehittäjien toimittamista moduuleista ja modulaarisesta JDK: sta
- Rajoitettujen versiorajoitusten vaatiminen ja täytäntöönpano
JEP (Java Enhancement Ehdotus) 200
Heinäkuussa 2014 luotu Java Enhancement -ehdotus 200 pyrkii määrittelemään modulaarisen rakenteen JDK: lle. JEP 200 perustuu Jigsaw-kehykseen helpottaakseen JDK: n segmentointia Java 8 Compact -profiilien mukaisesti moduulijoukkoiksi, jotka voidaan yhdistää kokoamis-, koontiajan ja käyttöönoton aikana. Nämä moduulien yhdistelmät voidaan sitten ottaa käyttöön pienennettyinä ajonaikaisina ympäristöinä, jotka koostuvat Jigsaw-yhteensopivista moduuleista.
JEP 201
JEP 201 pyrkii rakentamaan Jigsawille JDK-lähdekoodin uudelleenjärjestämiseksi moduuleiksi. Nämä moduulit voidaan sitten koota erillisiksi yksiköiksi parannetulla rakennusjärjestelmällä, joka panee täytäntöön moduulin rajat. JEP 201 ehdottaa lähdekoodin uudelleenjärjestelyjärjestelmää koko JDK: ssa, jossa korostetaan moduulirajat lähdekoodipuiden ylimmällä tasolla.
Penrose
Penrose hallinnoi palapelin ja OSGin välistä yhteentoimivuutta. Erityisesti se helpottaisi kykyä muokata OSGi-mikrotermiä, jotta modifioidussa ytimessä käynnissä olevat niput voisivat käyttää Jigsaw-moduuleja. Se luottaa siihen, että moduuleja kuvataan JSON: n avulla.
Suunnitelmat Java 9: lle
Java 9 on ainutlaatuinen Java-julkaisu. Ainutlaatuisen tekee modulaaristen komponenttien ja segmenttien käyttöönotto koko JDK: ssa. Tärkeimmät modulaarisuutta tukevat ominaisuudet ovat:
- Modulaarinen lähdekoodi: Java 9: ssä JRE ja JDK organisoidaan uudelleen yhteentoimiviksi moduuleiksi. Tämä mahdollistaa skaalattavien ajonaikojen luomisen, jotka voidaan suorittaa pienillä laitteilla.
- Segmentoitu koodivälimuisti: Vaikka Java 9: n uusi segmentoitu koodivälimuisti ei ole pelkästään modulaarinen palvelu, se noudattaa modulaation henkeä ja nauttii samoista eduista. Uusi koodivälimuisti tekee älykkäät päätökset koota usein käytetyt koodisegmentit natiivikoodiksi ja tallentaa ne optimoitua hakua ja tulevaa suoritusta varten. Kasa segmentoidaan myös 3 erilliseen yksikköön: ei-menetelmä-koodi, joka tallennetaan pysyvästi välimuistiin; koodi, jolla on mahdollisesti pitkä elinkaari (tunnetaan nimellä "profiloimaton koodi"); ja koodi, joka on ohimenevä (tunnetaan nimellä "profiloitu koodi").
- Rakennuksen aikaiset täytäntöönpanotoimet: Koontijärjestelmää parannetaan JEP 201: n kautta moduulirajojen kokoamiseksi ja valvomiseksi.
- Käyttöönottotilat: Palapelihankkeessa tarjotaan työkaluja, jotka tukevat moduulin rajoja, rajoituksia ja riippuvuuksia käyttöönoton yhteydessä.
Java 9: n varhaisen käytön julkaisu
Vaikka Java 9: n tarkka julkaisupäivä on edelleen mysteeri, voit ladata varhaisen käyttöoikeuden julkaisun Java.net-sivustosta.
Tiivistettynä
Tämä artikkeli on ollut yleiskatsaus modulaarisuudesta Java-alustalla, mukaan lukien modulaarisuuden mahdollisuudet Java 9: ssä. Selitin, kuinka pitkät ongelmat, kuten luokkatien helvetti, lisäävät tarvetta modulaarisemmalle Java-arkkitehtuurille ja keskustelin uusimmista modulaarisuuksista Java-sovellukseen ehdotetut ominaisuudet. Sitten kuvasin ja otin asiayhteyteen jokaisen Java-modulaarisuuden ehdotuksen tai alustan, mukaan lukien OSGi ja Project Jigsaw.
Modulaarisemman Java-arkkitehtuurin tarve on selvä. Nykyiset yritykset eivät ole onnistuneet, vaikka OSGi onkin lähellä. Java 9 -julkaisussa Project Jigsaw ja OSGi ovat tärkeimmät pelaajat Java-modulaarisessa tilassa, ja Penrose tarjoaa mahdollisesti niiden välisen liiman.
Tämän tarinan "Modulaarisuus Java 9: ssä: Projektin palapelin, Penrosen ja OSGin kerääminen" julkaisi alun perin JavaWorld.
