Šajā rakstā ir sniegts pārskats par priekšlikumiem, specifikācijām un platformām, kuru mērķis ir padarīt Java tehnoloģiju modulārāku Java 9. Es apspriedīšu faktorus, kas veicina nepieciešamību pēc modulārākas Java arhitektūras, īsi aprakstīšu un salīdzināšu piedāvātos risinājumus, un ieviest trīs Java 9 plānotos modularitātes atjauninājumus, ieskaitot to iespējamo ietekmi uz Java attīstību.
Kāpēc mums nepieciešama Java modularitāte?
Modularitāte ir vispārējs jēdziens. Programmatūrā tas attiecas uz programmas vai skaitļošanas sistēmas rakstīšanu un ieviešanu kā unikālu moduļu skaitu, nevis kā vienotu, monolītu dizainu. Pēc tam tiek izmantota standartizēta saskarne, lai moduļi varētu sazināties. Programmatūras konstrukciju vides sadalīšana atsevišķos moduļos palīdz mums samazināt sasaisti, optimizēt lietojumprogrammu izstrādi un samazināt sistēmas sarežģītību.
Modularitāte ļauj programmētājiem veikt funkcionalitātes testēšanu atsevišķi un iesaistīties paralēlos attīstības centienos noteiktā sprinta vai projekta laikā. Tas palielina efektivitāti visā programmatūras izstrādes dzīves ciklā.
Daži īsta moduļa raksturojošie atribūti ir:
- Autonomā izvietošanas vienība (vaļīga sakabe)
- Konsekventa un unikāla identitāte (moduļa ID un versija)
- Viegli identificējamas un atklātas prasības un atkarības (standarta kompilēšanas laika un izvietošanas iespējas un metainformācija)
- Atvērta un saprotama saskarne (sakaru līgums)
- Slēpta ieviešanas informācija (iekapsulēšana)
Sistēmām, kas izveidotas, lai efektīvi apstrādātu moduļus, jāveic šādas darbības:
- Atbalstiet modularitāti un atkarības atklāšanu apkopošanas laikā
- Izpildiet moduļus izpildlaika vidē, kas atbalsta ērtu izvietošanu un pārdalīšanu bez sistēmas dīkstāves
- Ieviesiet skaidru un stabilu izpildes dzīves ciklu
- Nodrošiniet iespējas vienkāršai reģistrēšanai un moduļu atrašanai
Objektīvie, uz komponentiem un pakalpojumiem orientētie risinājumi visi ir mēģinājuši iespējot tīru modularitāti. Katram risinājumam ir savs dīvainību kopums, kas tomēr neļauj tam sasniegt moduļu pilnību. Īsi apsvērsim.
Java klases un objekti kā moduļu konstrukcijas
Vai Java objektorientētais raksturs neatbilst modularitātes prasībām? Galu galā objektorientētā programmēšana ar Java uzsver un dažreiz īsteno unikalitāti, datu iekapsulēšanu un brīvu savienošanu. Lai gan šie punkti ir labs sākums, ievērojiet modularitātes prasības, kas nav atbilst Java objektorientētajam ietvaram: identitāte objekta līmenī nav uzticama; saskarnes nav versijas: un klases izvietošanas līmenī nav unikālas. Brīva savienošana ir labākā prakse, taču tā noteikti netiek piemērota.
Ja ir grūti atkārtoti izmantot klases Java, ja trešo personu atkarības tiek tik viegli ļaunprātīgi izmantotas. Kompilēšanas laika rīki, piemēram, Maven, cenšas novērst šo trūkumu. Valodas pēc faktiem, piemēram, atkarības ievadīšana un vadības inversija, palīdz izstrādātājiem mūsu mēģinājumos kontrolēt izpildlaika vidi, un dažreiz tie izdodas, it īpaši, ja tos lieto stingri. Diemžēl šī situācija ļauj moduļveida videi izveidot īpašumtiesību principus un konfigurācijas.
Java arī pievieno maisījumam pakotņu nosaukumvietas un darbības jomas redzamību kā moduļu sastādīšanas laika un izvietošanas laika mehānismu izveides līdzekli. Bet šīs valodas iezīmes ir viegli apietas, kā es paskaidrošu.
Iepakojumi kā modulārais risinājums
Paketes mēģina Java programmēšanas ainavai pievienot abstrakcijas līmeni. Tie nodrošina iespējas unikālām nosaukumvietu un konfigurācijas kontekstu kodēšanai. Diemžēl paketes konvencijas ir viegli apietas, un tas bieži rada bīstamu apkopošanas laika savienojumu vidi.
Pašlaik Java modularitātes stāvoklis (izņemot OSGi, kuru es drīz apspriedīšu) visbiežāk tiek panākts, izmantojot pakotņu nosaukumvietas, JavaBeans konvencijas un patentētas ietvara konfigurācijas, piemēram, tās, kas atrodamas pavasarī.
Vai JAR faili nav pietiekami modulāri?
JAR faili un izvietošanas vide, kurā tie darbojas, ievērojami uzlabo daudzās mantotās izvietošanas konvencijas, kas citādi ir pieejamas. Bet JAR failiem nav raksturīgas unikalitātes, izņemot reti izmantoto versijas numuru, kas ir paslēpts .jar manifestā. JAR fails un izvēles manifests netiek izmantoti kā modularitātes konvencijas Java izpildlaika vidē. Tātad failā esošo klašu pakotņu nosaukumi un viņu dalība klases ceļā ir vienīgās JAR struktūras daļas, kas izpildes videi piešķir modularitāti.
Īsāk sakot, JAR ir labs modularizācijas mēģinājums, taču tie neatbilst visām prasībām patiesi modulārai videi. Rāmji un platformas, piemēram, Spring un OSGi, izmanto modeļus un JAR specifikācijas uzlabojumus, lai nodrošinātu vidi ļoti spējīgu un modulāru sistēmu veidošanai. Laika gaitā pat šie rīki pakļausies ļoti neveiksmīgam JAR specifikācijas JAR elles blakus efektam!
Klases ceļš / JAR elle
Kad Java izpildlaika vide ļauj patvaļīgi sarežģītus JAR ielādes mehānismus, izstrādātāji zina, ka tie atrodas klases ceļa elle vai JAR elle. Šādu stāvokli var izraisīt vairākas konfigurācijas.
Vispirms apsveriet situāciju, kad Java lietojumprogrammu izstrādātājs nodrošina atjauninātu lietojumprogrammas versiju un ir iesaiņojis to JAR failā ar tādu pašu nosaukumu kā vecā versija. Java izpildlaika vide nenodrošina apstiprināšanas iespējas pareiza JAR faila noteikšanai. Izpildes laika vide vienkārši ielādēs klases no JAR faila, kuru tā vispirms atrod vai kas atbilst vienam no daudziem klases ceļa noteikumiem. Tas labākajā gadījumā noved pie negaidītas uzvedības.
Vēl viens JAR elles gadījums rodas, kad divas vai vairākas lietojumprogrammas vai procesi ir atkarīgi no dažādām trešās puses bibliotēkas versijām. Izmantojot standarta klases ielādes iespējas, izpildlaika laikā būs pieejama tikai viena trešās puses bibliotēkas versija, kas radīs kļūdas vismaz vienā lietojumprogrammā vai procesā.
Pilnvērtīgai un efektīvai Java moduļu sistēmai vajadzētu atvieglot koda atdalīšanu atsevišķos, viegli saprotamos un brīvi savienotos moduļos. Atkarības būtu skaidri jānorāda un stingri jāīsteno. Jābūt pieejamām iespējām, kas ļauj moduļus uzlabot, negatīvi neietekmējot citus moduļus. Modulārai izpildlaika videi vajadzētu dot iespēju konfigurācijām, kas raksturīgas noteiktam domēnam vai vertikālajam tirgum, tādējādi samazinot vides palaišanas laiku un sistēmas nospiedumu.
Java modularitātes risinājumi
Līdztekus līdz šim minētajām modularitātes funkcijām nesenie centieni papildina vēl dažus. Šīs funkcijas ir paredzētas, lai optimizētu veiktspēju un ļautu paplašināt izpildlaika vidi:
- Segmentēts pirmkods: Pirmkods, kas sadalīts atsevišķos, kešatmiņā saglabātos segmentos, un katrā no tiem ir īpašs apkopotā koda veids Mērķi ir koda, kas nav metode, izlaišana atkritumu slaucīšanas laikā, pakāpeniska būvēšana un labāka atmiņas pārvaldība.
- Izpildes laika izpildes: Valoda tiek konstruēta, lai ieviestu nosaukumvietas, versijas, atkarības un citas.
- Izvietošanas iespējas: Atbalsts mērogotā izpildlaika vides izvietošanai atbilstoši īpašām vajadzībām, piemēram, mobilo ierīču videi.
Šīs funkcijas ir mēģinājušas atvieglot vairākas modularitātes specifikācijas un ietvarstruktūras, un dažas no tām nesen izvirzījušās Java 9 priekšlikumu augšgalā. Šeit ir sniegts Java modularitātes priekšlikumu pārskats.
JSR (Java specifikācijas pieprasījums) 277
Pašlaik neaktīvs ir Java Specification Request (JSR) 277, Java moduļu sistēma; ko Sun ieviesa 2005. gada jūnijā. Šī specifikācija aptvēra lielāko daļu to pašu jomu, kur OSGi. Tāpat kā OSGi, arī JSR 277 nosaka moduļu atklāšanu, ielādi un konsekvenci, ar nelielu atbalstu izpildlaika modifikācijām un / vai integritātes pārbaudei.
JSR 277 trūkumi ietver:
- Nav dinamiskas moduļu / saišķu ielādes un izkraušanas
- Veicot laiku, netiek pārbaudīta klases un telpas unikalitāte
OSGi (Open Service Gateway Initiative)
OSGI alianse, kuru 1998. gada novembrī ieviesa OSGI platforma, ir visplašāk izmantotā modularitātes atbilde uz formālo Java jautājumu. Pašlaik 6. laidienā OSGi specifikācija ir plaši pieņemta un izmantota, īpaši vēlīnā.
Būtībā OSGi ir modulāra sistēma un Java programmēšanas valodas pakalpojumu platforma, kas realizē pilnīgu un dinamisku komponentu moduli moduļu, pakalpojumu, izvietojamu saišķu utt. Veidā.
OSGI arhitektūras primārie slāņi ir šādi:
- Izpildes vide: Java vide (piemēram, Java EE vai Java SE), kurā darbojas pakete.
- Modulis: Ja OSGi ietvars apstrādā komplekta moduļu aspektus. Šeit tiek apstrādāti grupas metadati.
- Dzīves cikls: Šeit notiek saišķu inicializēšana, palaišana un apturēšana.
- Pakalpojuma reģistrs: Kur saišķos ir uzskaitīti viņu pakalpojumi, lai tos varētu atklāt citi.
Viens no lielākajiem OSGi trūkumiem ir oficiāla mehānisma trūkums vietējās pakotnes instalēšanai.
JSR 291
JSR 291 ir Java SE dinamisks komponentu ietvars, kas balstīts uz OSGi, pašlaik ir izstrādes pēdējā posmā. Šīs pūles ir vērstas uz OSGi iekļaušanu galvenajā Java, kā Java mobilajai videi darīja JSR 232.
JSR 294
JSR 294 definē meta moduļu sistēmu un deleģē spraudņu moduļu (versijas, atkarības, ierobežojumi utt.) Faktisko iemiesojumu ārējiem pakalpojumu sniedzējiem. Šī specifikācija ievieš valodas paplašinājumus, piemēram, "superpaketes" un ar hierarhiju saistītus moduļus, lai atvieglotu modularitāti. Stingra iekapsulēšana un atšķirīgas kompilācijas vienības ir arī spec īpašnieka uzmanības centrā. JSR 294 pašlaik ir miera stāvoklī.
Projekts finierzāģis
Projekts Finierzāģis ir visiespējamākais moduļuma kandidāts Java 9. Finierzāģis cenšas izmantot valodas konstrukcijas un vides konfigurācijas, lai definētu Java SE mērogojamu moduļu sistēmu. Galvenie finierzāģa mērķi ir:
- Padarot Java SE izpildlaika un JDK mērogošanu ļoti vienkāršu līdz mazām ierīcēm.
- Uzlabot Java SE un JDK drošību, aizliedzot piekļuvi iekšējām JDK API un ieviešot un uzlabojot
SecurityManager.checkPackageAccessmetodi. - Lietojumprogrammu veiktspējas uzlabošana, optimizējot esošo kodu, un atvieglojot programmas nākotnes optimizācijas paņēmienus.
- Lietojumprogrammu izstrādes vienkāršošana Java SE, ļaujot bibliotēkas un lietojumprogrammas veidot no izstrādātāja ieguldītiem moduļiem un modulārā JDK
- Pieprasīt un ieviest ierobežotu versijas ierobežojumu kopumu
JEP (Java uzlabošanas priekšlikums) 200
Java Enhancement 200. priekšlikuma, kas izveidots 2014. gada jūlijā, mērķis ir noteikt JDK moduļu struktūru. JEP 200 balstās uz finierzāģu sistēmu, lai atvieglotu JDK segmentēšanu atbilstoši Java 8 Compact profiliem moduļu komplektos, kurus var apvienot sastādīšanas laikā, būvēšanas laikā un izvietošanas laikā. Pēc tam šīs moduļu kombinācijas var izvietot kā samazinātas izpildlaika vides, kas sastāv no finierzāģim atbilstošiem moduļiem.
JEP 201
JEP 201 cenšas balstīties uz finierzāģi, lai pārveidotu JDK pirmkodu moduļos. Pēc tam šos moduļus var apkopot kā atšķirīgas vienības ar uzlabotu būvēšanas sistēmu, kas nodrošina moduļu robežas. JEP 201 visā JDK piedāvā avota koda pārstrukturēšanas shēmu, kas izceļ moduļu robežas pirmkodu koku augšējā līmenī.
Penrose
Penrose pārvaldītu Jigsaw un OSGi savietojamību. Konkrēti, tas atvieglotu iespēju modificēt OSGi mikrokoderus, lai modificētajā kodolā darbojošie saišķi izmantotu finierzāģa moduļus. Tas paļaujas uz JSON izmantošanu, lai aprakstītu moduļus.
Java 9 plāni
Java 9 ir unikāls galvenais Java izlaidums. Unikālu padara moduļu komponentu un segmentu ieviešana visā JDK. Galvenās funkcijas, kas atbalsta modularizāciju, ir:
- Moduļu pirmkods: Java 9 versijā JRE un JDK tiks reorganizēti par savietojamiem moduļiem. Tas ļaus izveidot mērogojamus izpildlaikus, kurus var izpildīt mazās ierīcēs.
- Segmentēta koda kešatmiņa: Lai gan tā nav tikai modulāra iespēja, jaunā Java 9 segmentētā koda kešatmiņa sekos modularizācijas garam un baudīs dažas no tām pašām priekšrocībām. Jaunā koda kešatmiņa pieņems saprātīgus lēmumus, lai apkopotu bieži pieejamos koda segmentus vietējā kodā un saglabātu tos optimizētai uzmeklēšanai un izpildei nākotnē. Kaudze arī tiks segmentēta 3 atšķirīgās vienībās: kods, kas nav paņēmiens, kas tiks pastāvīgi saglabāts kešatmiņā; kods, kura dzīves cikls ir potenciāli ilgs (pazīstams kā "neprofilēts kods"); un īslaicīgs kods (pazīstams kā "profilētais kods").
- Izpildes laika izpildes: Ar JEP 201 palīdzību tiks uzlabota būvēšanas sistēma, lai apkopotu un ieviestu moduļa robežas.
- Izvietošanas iespējas: Jigsaw projektā tiks nodrošināti rīki, kas izvietošanas laikā atbalstīs moduļa robežas, ierobežojumus un atkarības.
Java 9 agrīnas piekļuves izlaišana
Lai gan precīzs Java 9 izlaišanas datums joprojām ir noslēpums, agrīnās piekļuves laidienu varat lejupielādēt vietnē Java.net.
Noslēgumā
Šis raksts ir bijis pārskats par modularitāti Java platformā, ieskaitot modularitātes izredzes Java 9. Es paskaidroju, kā ilgstoši jautājumi, piemēram, klases ceļa elle, veicina nepieciešamību pēc modulārākas Java arhitektūras, un apspriedu dažus no jaunākajiem jaunajiem modularitātēm Java programmai piedāvātās funkcijas. Pēc tam es aprakstīju un kontekstualizēju katru Java modularitātes priekšlikumu vai platformu, ieskaitot OSGi un Project Jigsaw.
Nepieciešamība pēc modulārākas Java arhitektūras ir skaidra. Pašreizējie mēģinājumi ir nepietiekami, lai gan OSGi nāk ļoti tuvu. Java 9 izlaidumam Project Jigsaw un OSGi būs galvenie spēlētāji Java modulārajā telpā, un Penrose, iespējams, nodrošinās līmi starp tiem.
Šo stāstu "Modularitāte Java 9: Programmu finierzāģu, Penrose un OSGi sakopošana" sākotnēji publicēja JavaWorld.
