Java 9 újdonságai – 6. rész

Process API újítások

Előzmények

A Java korai verzióiban elég nehézkes volt új folyamatot indítani. Ehhez csak a Runtime.getRuntime().exec() metódus állt rendelkezésünkre. 2004-ben, a Java 5 megjelenésével ez megváltozott, innentől kezdve elérhetővé vált a ProcessBuilder API, amivel könnyebben lehetett létrehozni új folyamatokat. Nézzük meg, hogy mivel bővül a process API repertoárja a Java 9-ben!

process API szemléltetésére szolgáló ábra

ProcessHandle interfész

Az új ProcessHandle interfész új lehetőségeket nyit számunkra a natív folyamatok kezeléséhez. A Java 5 óta elérhető ProcessBuilder által előállított Process objektumoktól elkérhető azok ProcessHandle-je.

A ProcessHandle feladata, hogy azonosítson egy folyamatot és lehetővé tegye, hogy különféle műveleteket végezzünk el rajta. Példányok a következő statikus factory metódusok segítségével hozhatók létre:

Statikus factory metódusLétrehozott ProcessHandle objektum
current()Az aktuális folyamathoz tartozó ProcessHandle objektummal tér vissza.
of(long pid)Optional<ProcessHandle> objektummal tér vissza, ami a megadott natív folyamat azonosítóhoz tartozik.
children()Stream<ProcessHandle> objektummal tér vissza, ami az aktuális folyamathoz tartozó közvetlen gyerek folyamatokat tartalmazza.
descendants()Stream<ProcessHandle> objektummal tér vissza, ami az aktuális folyamathoz tartozó gyerek folyamatokat tartalmazza, rekurzívan azok gyerek folyamataival együtt.
parent()Optional<ProcessHandle> objektummal tér vissza, ami az aktuális folyamat szülő folyamatát tartalmazza.
allProcesses()Egy olyan Stream<ProcessHandle> objektummal tér vissza, ami az aktuális folyamat által látható össze folyamat ProcessHandle-jét tartalmazza.

További hasznos metódusok, amit a ProcessHandle interfész elérhetővé tesz:

ProcessHandle metódusLeírás
info()ProcessHandle.Info objektummal tér vissza, ami az adott folyamathoz tartozó információkat tartalmazza.
isAlive()boolean-nel tér vissza, ami azt jelzi, hogy az adott folyamat él-e még.
pid()A natív folyamat azonosítóval tér vissza, ami alapján az operációs rendszer számon tartja az adott folyamatot.
supportsNormalTermination()boolean-nel tér vissza, ami azt jelzi, hogy támogatja-e a normál leállítást az adott folyamat, vagy rákényszerítve, azonnal állítja le a folyamatot.
onExit()CompletableFuture<ProcessHandle> objektummal tér vissza, ami arra használható, hogy az adott folyamat befejeződésekor, szinkron vagy szinkron módon, elindítsunk egy tetszőleges utasítást.
destroy()boolean-nel tér vissza, ami azt mutatja meg, hogy az adott folyamat leállítási kérelme sikeresen fel lett-e dolgozva.

ProcessHandle.Info interfész

Egy folyamatra egy adott időpillanatban vonatkozó információit tartalmazza. Ezek az információk korlátozottak lehetnek az információkat igénylő folyamatra vonatkozó operációs rendszeri jogosultságok függvényében.

ProcessHandle.Info metódusLeírás
arguments()Az adott folyamat argumentumait tartalmazó String tömböt tartalmazó Optional objektummal tér vissza.
command()Az adott folyamathoz tartozó alkalmazás nevét tartalmazó Optional-lel tér vissza.
commandLine()Az adott folyamathoz tartozó parancssort tartalmazó Optional-lel tér vissza.
startInstant()Az adott folyamat indításának pillanatát tartalmazó Optional-lel tér vissza.
totalCpuDuration()Az adott folyamat által felhasznált CPU-időt tartalmazó Optional-lel tér vissza.
user()Az adott folyamat felhasználóját tartalmazó Optional-lel tér vissza.

Példa

Összefoglalás

A Java 9 process API újításai segítségével szebb kódot írhatunk. A korábbi verzióban bevezetett ProcessBuilder is jelentős lépés volt a helyes irányba, de az új lehetőségek, amiket az új interfészek, illetve az azokat megvalósító osztályok biztosítanak, fontos új eszközöket adnak a programozók kezébe, amikkel könnyebben kezelhetővé váltak a natív folyamatok.

Ha a többi Java 9-es újítás is érdekel, akkor böngészd bátran a többi blog posztot is ebben a témában!

A hivatalos javadoc-ban minden további részletet megtalálsz:

ProcessBuilder, Process, ProcessHandle, ProcessHandle.Info, CompletableFuture.

Ha tetszett, oszd meg!

Minden, amit mindig is tudni akartál a programozásról (de féltél megkérdezni)

A programozói karrierről, a diploma szükségességéről, önfejlesztésről és szórakozásról beszélgettünk exkluzív interjú keretében Almási Zsolttal, partnercégünknél, a P92-nél dolgozó fejlesztővel.

 

Egy finom tejeskávé társaságában az A&K Akadémia egyik tantermében

Mesélj kicsit magadról, hogyan lettél programozó?

Neumann János Számítástechnikai Szakgimnáziumba jártam. Akkor úgy gondoltam, hogy ebből 5 év elég is volt, nem akarok programozó lenni. Elmentem két egyetemre, de egyiket sem fejeztem be, fél évig jártam mindkettőre. Több bulin voltam, mint órán, eléggé elhanyagoltam. 🙂 Aztán elvégeztem egy OKJ-t. Ezt csak azért csináltam meg, hogy legyen papírom róla, hogy informatikában jártas vagyok. Véletlenül találkoztam a mostani főnökömmel és beszélgetés közben kiderült, hogy állást keresek, és tudta, hogy értek a programozáshoz, és bár diplomám nincs, behívtak interjúra és végül fel is vettek. Gyorsan pörögtek az események. Elvégeztem egy 6 hónapos belső képzést és aláírtam egy két éves szerződést. Eddig 3 projektben vettem részt. Körülbelül májusban lesz két éve, hogy itt vagyok.

Mi volt a legnehezebb az elején?

Egy olyan keretrendszerrel találkoztam, amit egyáltalán nem ismertem, ráadásul a keretrendszer maga a kód fele, tehát ha nem ismerem, akkor nem ismerem magát a kódot sem. Azt volt nehéz megtanulni, hogy hogyan kell használni. Ráadásul a kód sem volt egyszerű, egy metódus többezer sorral és benne nagy “if”-ekkel.

Hazaviszed a munkát?

Csak ha van kedvem, és ha érdekel annyira, hogy foglalkozzak vele otthon is. Többet szoktam azon gondolkodni, hogy hogyan lehet egy feladatot röviden megoldani, mint hogy nekiálljak a hosszú útnak. Az idő egy része azzal telik, hogy gondolkodom a rövidebb, könnyebb megoldáson. Nem fogok órákat gépelni, hogy ha meg tudom csinálni sokkal egyszerűbben is. A Java-ban az a nehéz, hogy rengeteget kell benne kódolni. Semmi kedve az embernek órákig csinálni. Keresni kell a rövidebb utakat, mert biztosan meg lehet csinálni egyszerűbben is. 🙂

Ha újrakezdhetnéd, akkor mit tennél másképp?

Ha újrakezdhetném, akkor azonnal, ahogy elvégeztem a középiskolát, elmentem volna egy ilyen helyre dolgozni, mint a P92. Ennek van értelme. Esetleg mellette megcsináltam volna az egyetemet, de nem biztos. Szerintem az egyetemnek önmagában semmi értelme nincs, úgy pedig pláne nem, hogy arra 3,5 – 5 évet tisztán rászánjak. Felesleges ebben a szakmában. Itt sokkal többet számít a gyakorlati tapasztalat.

Szerinted mit jelent, ha valaki diplomás?

Az egyetem önmagában annyit jelent, hogy van elég kitartásod elvégezni, tudsz tanulni, képes vagy magadra erőltetni a folyamatos tanulást, különben nem tudod befejezni az egyetemet. Ebben jó. Illetve bizonyos szinteken már kell a matek is, és ott tanítanak ilyet. De ez is ritka, és csak bizonyos pozíciókban van rá szükség. Külön cégek foglalkoznak ilyesmivel. Üzleti szoftverekhez nem kell matek, itt már meg van írva az a rész, csak használni kell tudni.

Gondolkodtál azon, hogy most utólag elvégzed az egyetemet?

Hááát… legfeljebb csak a papírért. Talán. De minden álláshirdetésnél az van odaírva, hogy BSc, MSc vagy azzal egyenértékű tapasztalat az adott területen. Az meg megvan. 🙂

Érezted valaha hátrányos helyzetben magad azért, mert nincs felsőfokú végzettséged?

Nem. Még nem fordult elő, hogy a papír hiányzott volna. Az ott megszerezhető tudás sem nagyon hiányzott. A matek egyszer jól jött volna, mert volt egy könyv a funkcionális programozásról, amit el akartam olvasni, de nagyon belemerült a részletekbe, és nem minden részt értettem pontosan.

Mit tanultál meg a felvételi utáni belső képzésen?

A fél éves belső képzésen a sebességet növeltük, mert ezen a munkahelyen azért kell tartani egy bizonyos tempót. Ezen kívül megtanították, hogy hogyan tudok utána nézni dolgoknak, hogyan tudom fejleszteni saját magam. Meg kellett szokni, hogy mindig újabb és újabb dolgoknak kell utána nézni.

Milyen könyveket ajánlanál kezdőknek?

The pragmatic programmert, a Clean Codert. Egyik sem kódspecifikus, inkább ilyen soft skilles. Ezenkívül a Java Core-t és a Clean codingot is mindenképp ajánlom. Ezeket angolul olvastam, magyarul nincsenek olyan jó könyvek, és ha le is fordítják magyarra, sosem fogod úgy látni azokat a kifejezéseket. A gyakorlatban úgy is minden angolul van. Ha megtanulod magyarul, és rákeresel, akkor nem találsz róla semmit, és fejben átfordítani utána elég nehéz. Jobb eredetiben olvasni.

Szerinted mennyire fontos a szakmai életben az angol? Te hogyan tanultál meg angolul?

Régebben heti 14 órában tanultam az angolt, és most angolul olvasok, tanulok, dolgozom. Az, hogy angolul kell tudni, az nem lehet kérdés. A könyveket meg kell tudni érteni, hogy tudd magad otthon fejleszteni. Informatikai szaknyelvből nem középszinten vagyok, sokkal magasabban. Lehet, hogy középszinten vagyok angolul mondjuk főzésből, mert zöldséget csak kb. tíz darabot tudok mondani. 🙂 De szaknyelvből kellenek a szavak. Sok mindent nem is tudok magyarul, csak angolul.

Most lehet, hogy németül kellene megtanulnom, mert gondolkodtam azon is, hogy kimennék Bécsbe dolgozni. Az is csak 3 óra vonattal, nem távolság, bár ha elkészül a bullet train akkor csak 13 perc lesz. 🙂 Hamarabb kiérnék vele Bécsbe, mint innen a Nyugatiba. Megérné kimenni dolgozni, mert ott még magasabbak a fizetések. A normál fizetés is 60 ezer euró évente. Még ha a harmadik legdrágább európai város, akkor is megéri.

Oda nem elég az angol nyelvtudás?

Az angol alapelvárás, de azért azt minden német álláshirdetésben írják, hogy egy kommunikációs szinten illik tudni németül is. Lehet, hogy a munkatársak egy része nem beszél angolul? Nem tudom.

Visszatérve a korábbi gondolathoz: ha jól értem, te most saját magadat fejleszted?

Igen. Olvasni és tanulni egyszerűen muszáj. Lehet egyedül is tanulni, de persze az a legjobb, ha van egy mentora az embernek, aki segít. Az nagy előny. Csak nehéz jó mentort találni. Nekem szerencsém volt itt a cégnél, mert mellettem volt István, aki csak úgy dobálta nekem a linkeket és könyvcímeket, hogy mi mindent olvassak el, tanuljak meg. Nagyon sokat segített a kifejezésekkel, hogy mire érdemes rákeresni. Ez tök jó volt, mert igazából rám volt bízva, hogy mennyit tanulok. Nagyon sokat segített benne.

Mit tanácsolnál egy teljesen kezdőnek, aki most kezd el először programozni?

Keressen rá a népszerű programnyelvekre, és válasszon egy szimpatikusat közülük! Szerintem a Java nagyon jó. De ahhoz, hogy önállóan tovább tudja saját magát fejleszteni, ahhoz először valahogy el kell érnie egy bizonyos szintet. Hiszen, ha nem tudja, hogy mit keressen, hogyan működik ez az egész, akkor esélytelen. A kezdeteknél mindenképp jó egy mentor. Ha nem tudja, hogy miben kell fejlődnie, akkor az nagy pech, ha egyedül van, és nincs kitől kérdezni, tanácsot kérni.

Milyen a jó mentor, és miért?

Legfőképp türelmes. Programozni elég nehéz dolog. Nem olyan egyszerű, mint ezt olyan sokan mondják, hogy ott van, elég elolvasni és kész. Sok helyen ez jön le a netről, de ez nem igaz. Próbálják könnyűnek mutatni, pedig nem egy könnyű dolog, szerintem. A valódi munka nem arról szól, hogy írsz valami újat. Bele kell nyúlni a meglevőbe! Senki a bolygón nem kap olyan feladatot, hogy magától írjon, tisztán egy programot, ezt megmondom neked itt a széken ülve. A valóság arról szól, hogy egy már meglevő rendszerbe kell belenyúlni felelősséggel, és az nem egyszerű. És nap, mint nap ezt kell csinálni.

 

 Szerinted mire számítsanak a kezdők a tanfolyamunk alatt?

Lesznek nehéz pontok, amin át kell majd esniük ebben biztos vagyok. Mindenkinek lesz olyan, hogy nem érti meg, amit tanul, és ülnie kell rajta 3-4 napot, és még azután is szembe kell néznie azzal, hogy nem érti meg. Idő kell neki, mire az ember rááll. Még a mai napig is simán van olyan, hogy valamit nem tudok megcsinálni és akkor egy héttel később egyszer csak katt, és beugrik. És akkor megvan! Tehát türelem kell, mindenképp! Vannak dolgok, amikhez idő kell, nem megy másképp. Lesz olyan, hogy Andris elmondja egyféleképp, nem értik meg, másképp, harmadik módon és mondhatná tizenötféleképpen, akkor sem megy. Van ilyen. Az a helyzet már nem a magyarázaton múlik. Érnie kell a gondolatnak és majd hetekkel később meg lesz az a megoldás. Erre fel kell készülni. Mindenki másképp működik.

Az elmúlt évek során volt, hogy elvesztetted a motivációdat, és beleuntál?

Persze, unalmas részek is vannak. De mit lehet ilyenkor csinálni? Beleharapok az ajkamba és várok. 🙂 Meghallgatom, megnézem, és ennyi. Ha szükségem van rá, újra és újra rákeresek, utána nézek, és előbb-utóbb megmarad. Amikor gondolkodok rajta, akkor általában gyorsan megtanulom, de bemagolni semmit nem magolok be. Felesleges. A leghatékonyabb tanulás a gyakorlás. Én sokszor elég lusta vagyok ehhez, de én is látom, hogy kell. Be kellene áldozni 1-2 órát gyakorlásra.

Most, hogy ebben dolgozol, most is folyamatosan tanulsz?

A jó pap is holtig tanul, nekünk is muszáj. Szinte havonta változik az egész, tartani kell a lépést. Muszáj olvasni, tanulni. Nem szabad abbahagyni, mert lehagy a szakma. Be kell áldozni valamit, hogy legyen rá idő. Vagy kevesebbet dolgozok konkrétan, és utána járok dolgoknak, vagy ha munka mellett nem fér bele, akkor otthon kell utána járnom. A P92-nél is van lehetőség tanulni. Angolra is lehet járni, Clean code-ra, Refactoringra, stb., heti több órában.

Próbáltad már tanítani azt, amit megtanultál?

Nem, még nem. Ha valakinek van valami problémája, elakadása, akkor szívesen segítek, persze. De tanítani az más dolog.

Milyen álmaid vannak a jövőre nézve?

Több fizetés, esetleg külföld. Volt egy lehetőség itt a P92-nél is, hogy ki lehet menni Amerikába, meg is pályáztam, de sajnos nem engem választottak. Külföldön a legtöbb helyen angol kell, úgyhogy ez nem lesz gond a jövőben sem.

Jelenleg meg vagy elégedve a fizetéseddel?

Meg vagyok elégedve, igen. Többet keresek, mint más ismerőseim, nagy átlagban. Persze vannak elképzeléseim a jövőre nézve, ha lejár a két éves szerződésem, de ez így rendben volt eddig.

Nem aggódsz, hogy mi lesz utána?

Nem. Tele van a net álláshirdetésekkel. Nem szoktam sokat aggódni, nincs miért. Eddig sem kellett sokat interjúra járnom. Anno összesen 2 helyre adtam be a CV-met, a P92 volt az egyik. Szóval kb. azonnal sikerült. Szinte azonnal fel lettem véve. Válogatós vagyok és szerencsére lehet is válogatni. Régebben azért nem mertem sok helyre elküldeni a CV-met, mert tudtam, hogy nem felelek meg, de ez most már nincs így. Most már megfelelek, van önbizalmam.

Van hobbid?

Most tanulok japánul, király. 🙂 Nem a megtérülés miatt, csak egy drága hobbi. De amúgy is tele vagyok olyan hobbikkal, amik időt és pénzt vesznek el. 🙂

A PC-s játékoknak is van haszna, csak nehéz bemutatni őket, de az életben kijön, hogy ha jó vagy ezekben a játékokban, akkor az életben is bizonyos dolgokhoz valahogy jobban értesz. Csak erre nem lehet könnyen rámutatni, hogy ez és ez az a pont, amiben jobb vagy. Játszva tanul velük az ember. Szerintem jók. Ha tudsz párhuzamot vonni a játék és egy másik dolog között, akkor nagyon hasznos. Rendszerezni is megtanulsz, nyelvet gyakorolsz, reakcióidőd is nőhet, persze játéktól függ.

Ezeken kívül sokat olvasok. Egy évben elolvasok vagy húsz ponyvát (pl. a kedvenc kiadóm az Agave), és kb. három komolyabb szakmai könyvet. Egy 400 oldalas ponyvát kb. egy nap alatt elolvasok. Leülök, vagy az utcán olvasok, utazás közben, sőt, séta közben is tudok olvasni.

Hogy állsz a soft skillekkel?

El tudom adni magam. Ha már beszélgetnem kell valakivel, akkor már előnyben vagyok. Nekem ez nem gond. Komoly konfliktusom sem volt munkahelyen senkivel. Kreatív viták vannak, vagy van, hogy hangosabbak vagyunk, de semmi komoly.

A soft skillek fejlesztéséhez van valami jó tanácsod a most induló csoportnak?

Elküldeném őket egy buliba, hogy szedjenek fel egy nőt vagy férfit! Oda pont ugyan ezek a készségek kellenek. 🙂

Köszönjük szépen a beszélgetést! 🙂

Ha tetszett, oszd meg!

Java 9 újdonságai – 4. rész

Reactive Streams API – reaktív programozás

“A reaktív folyam egy kezdeményezés egy szabvány létrehozására, ami nem blokkoló háttérnyomás esetén is aszinkron folyam feldolgozást tesz lehetővé.” Mi van? – kérdezheted magadban. Pedig ez a lényeg. Bontsuk le kicsit, hogy honnan is származik ez az egész reaktív programozás és mi az értelme! Egy fontos koncepcióról van szó.

A reaktív programozás előzményei

Napjaink alkalmazásainak nagyon más követelményeknek kell megfelelniük, mint néhány évvel ezelőtt. Régebben elég volt, ha a program sok másodperccel később reagált a felhasználói inputra. Az se volt gond, ha néha pár órára leállították karbantartás miatt az egész rendszert. A legnagyobb rendszerek is csak néhány gigabájtnyi adatot kezeltek és az egész néhány szerveren futott.

Ezzel szemben ma a felhasználók inkább milliszekundumban mérhető válaszidőt várnak még a mobiljukról elért webes alkalmazásoktól is. Sokszor már petabájtnyi adatot kezelnek (a gigabájt egymilliószorosa) és felhő alapú klasztereken futnak, ahol több száz vagy ezer magos processzor szolgálja ki a számítási igényüket. A rendelkezésreállás 99,9999% vagy még több kilences a végén, attól függ, hogy milyen rendszerről van szó.

Egyszerűen túl nagy az elvárások közti különbség, és a régen bevált módszerek már nem elégítik ki ezeket az új igényeket. Szükség van tehát valami újra. Ez az új megközelítés a reaktív programozás.

Reaktív programozás

Nagyvállalatok egymástól függetlenül fejlesztették le az IT-s rendszereiket, amik között rengeteg hasonlóság volt, bár mindegyik másképp lett implementálva. Az igények már jól körvonalazódtak külön-külön. Milyen alkalmazásra van manapság szükség? Olyanra, ami

  • jól reagál (reactive): A program a vele folytatott kommunikáció során gyorsan ad választ, ezáltal a problémák is gyorsan felfedezhetők és orvosolhatók benne. Az ilyen rendszerek gyors és konzisztens módon adnak választ a kérésekre, megbízható felső korlátot specifikálnak válaszidőnek.
  • öngyógyító (resilient): A program hiba esetén is jól reagáló marad. A hibákat adott komponensen belül kell kezelni és a különböző komponenseket izolálni kell egymástól, ezáltal lehetővé téve, hogy a rendszer részei meghibásodhassanak és helyreállhassanak az egész rendszer kompromittálása nélkül. A komponensek helyreállítását egy másik külső komponensnek való feladatdelegálással lehet megoldani, a magas elérhetőséget pedig replikációval, amikor szükséges. Az adott komponenst használó klienseket nem terheljük meghibásodás kezelésével.
  • alkalmazkodó (elastic): Az alkalmazás akkor is jól reagál, amikor nagy terhelésnek van kitéve (pl. Neptun :-)). A reaktív rendszerek képesek detektálni a terhelés mértékét és ennek megfelelően allokálni erőforrásokat a programhoz. Ennek persze vonzata, hogy globális bottleneckektől mentes architektúrájú legyen a szoftver. Az ilyen rendszerek prediktív és reaktív skálázó algoritmusokat is támogatnak és az alkalmazkodókészségüket költséghatékony módon, mindenki által elérhető hardveren és szoftveren valósítják meg. (Vagyis nem kell hozzá szuperszámítógép.)
  • üzenet vezérelt (message driven): A program aszinkron üzenetátadáson alapul, amivel jól elhatárolhatók a komponensek egymástól és azok laza csatolását eredményezi. Ez az izoláció azt is lehetővé teszi, hogy a hibákat, mint üzeneteket delegáljuk. Az explicit üzenetátadással képessé válik a terheltség kezelésére, illetve alkalmazkodás érhető el azzal, hogy az üzenetsorok hosszát megfigyeli és formálja az igényeknek megfelelően.

Durván 3 évvel ezelőtt (2014. szeptember 16-án) tették közzé a második verzióját a “Reactive Manifesto”-nak, ami ezeket az igényeket fogalmazta meg.

Új programozási paradigma

A reaktív programozás tehát nem más, mint egy új programozási paradigma, ahol adatelemek aszinkron folyamát dolgozzuk fel, és ahol az alkalmazások az új adatelemekre azok megjelenésekor reagálnak.

Az adatok folyama nem más, mint időben egymás után levő adatelemek. Ezzel a módszerrel sok memóriát spórolhatunk meg és így hatékonyabbak lehetünk, mert az adatokat folyamként dolgozzuk fel, és nem kell egy memóriában összegyűlt adathalmazon végigiterálni.

Reaktív folyamok

Amikor a Reactive Manifesto alapján a reaktív folyam megközelítés útjára indult, akkor az volt a cél, hogy egy szabványos megoldást adjanak az aszinkron folyamfeldolgozásra, nem blokkoló háttérnyomás esetén. (Erre a háttérnyomásos dologra rögtön kitérünk részletesebben.) A fő kihívás nem az volt, hogy megoldást találjanak erre a problémára – hisz ekkor már több implementáció is létezett – hanem az, hogy a különböző megoldásokat összeolvasszák és megtalálják azt a minimális halmazát az interfészeknek, metódusoknak és protokolloknak, ami leírja a szükséges műveleteket és entitásokat, hogy elérhessük ezt a célt. Ha még mindig olvasod és idáig eljutottál, akkor megérdemelnél egy ingyen csokit!

Háttérnyomás

A háttérnyomás a kulcs koncepció itt, vagyis angolul a “back pressure”. Képzeld el a termelő (producer) és fogyasztó (consumer) feleket a rendszerben! A termelő adja és a fogyasztó kapja az üzeneteket. A fogyasztó feliratkozik a termelő adatforrására, ha szeretne tőle üzeneteket kapni. Ezek után, amikor egy új üzenet elérhetővé válik, a termelő a fogyasztónak egy callback metódusát meghívva feldolgozásra átadja az üzenetet.

Ha a termelő az üzeneteket nagyobb ütemben adja ki magából, mint ahogy a fogyasztó képes azt feldolgozni, akkor a fogyasztó rá lesz kényszerítve arra, hogy egyre több és több erőforrást ragadjon magához, amely jó eséllyel crash-eli a fogyasztót. Ennek megakadályozására szükség van egy mechanizmusra, hogy a fogyasztó értesíteni tudja a termelőt, hogy az üzenetküldési sebességet csökkentse. A termelő ekkor néhány különböző módszer közül választhat, amivel ezt a helyzetet kezelheti. Ezt a mechanizmust hívjuk háttérnyomásnak, vagyis back pressure-nek.

Blokkoló háttérnyomás

Ezt a legegyszerűbb elérni. Ha a termelő és a fogyasztó azonos szálon futnak, akkor az egyik végrehajtása blokkolja a másik végrehajtását. Probléma megoldva. Persze sok esetben ez nem eszközölhető. Gondolj csak arra, hogy a termelőnek nem csak ez az egy fogyasztója van, hanem több is, és mindegyik más sebességgel képes az üzeneteket feldolgozni. Legtöbbször nem is megoldható, hogy azonos szálon fussanak, mert különböző környezetekben vannak. Ilyen esetekben szükséges egy nem blokkoló háttérnyomási mechanizmus.

Nem blokkoló háttérnyomás

Ezt úgy érhetjük el, hogy a push stratégiánkat lecseréljük pull stratégiára. Vagyis nem akkor történik küldés, amikor a termelő készen áll az új üzenetekkel, hanem akkor, amikor a fogyasztó szól, hogy készen áll x üzenet fogadására. Ekkor a termelő pontosan ennyi üzenetet küld és vár, mielőtt továbbiakat küldene.

JDK 9 Flow API

A Java 9-ben megalkotott, a fentieket minimális méretű interfészekkel támogató API-ja a JEP 226: More Concurrency Updates keretein belül valósult meg. A következő 4 interfészt tartalmazza:

Java reaktív programozás Publisher és Subscriber szerepeket szemléltető ábra

Nomenklatúra

Korábbi elnevezéseink alapján (termelő, fogyasztó) a Subscriber a fogyasztó, de a Java 9 Flow API nomenklatúrája alapján a feliratkozó, a Publisher pedig a termelő, vagyis a publikáló (kiadó). Ezeket az elnevezéseket magyarul nem tartom szerencsésnek, így ezekre az angol nevükkel, vagy a magyarban meghonosult általános nevükkel fogok hivatkozni a továbbiakban.

Subscriber

A Subscriber feliratkozik a Publisher-hez annak subscribe metódusának meghívásával. Az adatelemek nem kerülnek kiküldésre a Subscriberhez, amíg azokat nem kéri explicite. A Subscriber Subscription-ön hívott metódusai szigorúan rendezettek. Az alkalmazás a következő callback-ekre tud reagálni, amik a Subscriberen vannak definiálva:

CallbackLeírás
onSubscribeEz a metódus kerül meghívásra minden egyéb Subscriber metódus előtt az adott Subscription esetén.
onNextEz a metódus kerül meghívásra egy Subscription következő eleménél.
onErrorEz a metódus kerül meghívásra egy helyreállíthatatlan hiba esetén, ami a Publisher-ben vagy Subscription-ben történt, ami után más Subscriber metódus már nem lesz hívva a Subscription által.

Ha egy Publisher hibába ütközik, ami nem teszi lehetővé adatelemek küldését a Subscriber-nek, akkor ezen a Subscriber-en az onError metódus kerül meghívásra és további üzeneteket nem fog kapni.

onCompleteEz a metódus akkor hívódik meg, amikor már ismertté válik, hogy további Subscriber metódushívások nem lesznek egy olyan Subscription-höz, ami még nem zárult le hibával.

Subscriber példa

Publisher

A Publisher az adatelemek folyamát továbbítja a feliratkozóknak. Ezt aszinkron módon teszi, általános esetben egy Executor segítségével. A Publisher-ek biztosítják, hogy a Subscriber metódushívások minden Subscription esetén szigorúan rendezett sorrendben történnek. Ha még mindig itt vagy velem, akkor az adatfolyamon érkezik neked egy újabb csoki reaktív módon.

Publisher példa a JDK SubmissionPublisher osztályával

Subscription

Egy Publisher-t és egy Subscriber-t köt össze. A Subscriber-ek csak akkor kapnak adatelemeket, amikor explicit kérik azokat, és bármikor visszavonhatják a Subscription segítségével.

MetódusLeírás
requestHozzáadja az adott n számú elemet az aktuálisan be nem teljesített kérelmekhez az adott Subscription-nél.
cancelA Subscriber-t leállítja, ami ezek után nem kap több üzenetet. A visszavonási kérelem nem azonnal történik.

Processor

A Processor egy olyan komponens, ami Subscriber-ként és Publisher-ként is viselkedik. A Publisher és Subscriber között helyezkedik el és átalakítja az egyik folyamot egy másikra. Több Processor-t is egymás után lehet kötni, és az utolsó Processor eredményét dolgozza fel a Subscriber. A JDK nem tartalmaz konkrét Processor implementációt, így ezt az API-t felhasználó programozónak kell megvalósítania.

Processor megvalósítására egy példa, ami String-ből Integer-t készít

Példa a Processor-ral történő folyam átalakításhoz

Konklúzió

A reaktív programozás megvalósulásához a Java 9 Flow API-ja egy jó kezdet. Megadja a fejlesztőknek azt a minimális interfész csomagot, amivel reaktív programok készíthetők, de időre lesz szükség, mire ennek az ökoszisztémája kialakul. Ha más termékekben is elérhetővé válik majd a reaktív programozás API-ja – mint például adatbáziskezelő rendszerekben – akkor megvalósulhatnak majd azok a modern alkalmazások, amik a Reactive Manifesto-ban leírt feltételeknek megfelelnek.
Ha érdekel a Java 9 további nyelvi újításai, akkor olvasd el a korábbi blog posztokat is a Java 9 témában!

Forrás:
https://community.oracle.com/docs/DOC-1006738
https://aboullaite.me/java-9-new-features-reactive-streams/

Ha tetszett, oszd meg!

Az első 90 nap támogatása

Az első 90 nap támogatása az A&K Akadémián

A magas színvonalú képzés és a fejlődést támogató munkahelyek elérése mellett nagyon fontos számunkra a további szakmai támogatásod is. Épp ezért ültettük át a gyakorlatba is a korábban a vezetők integrációja során alkalmazott ún. “első 90 nap támogatást”.

Mit jelent az első 90 nap támogatása?

első 90 nap nehézségeit szimbolizáló kép
Ne ugorj fejest egyedül az ismeretlenbe! Mi is veled ugrunk.

Az új szakmai kihívások, új munkahely vagy új pozíció betöltése jelentős nyomást, stresszt okoz az életedben, ráadásul az első hónapok teljesítménye alapvetően meghatározhatja a munkád hosszabb távú megítélését is. Mi szeretnénk megkönnyíteni számodra ezt az időszakot, ezért dolgoztuk ki ezt a támogatási rendszert. Az A&K Akadémia 90 napos támogatása heti konzultációkat tartalmaz, amely során fejlesztéssel kapcsolatos kérdésekben is segítünk, és egyéni coaching alkalmakkal is támogatjuk az elméletben tanultak gyakorlati alkalmazását, legyen szó beilleszkedési kérdésekről, csapatirányításról, vezető készségek fejlesztéséről, időmenedzsmentről, vagy a tudatos tervezés támogatásáról.

Mi történik, ha eléred a vágyott célt?

Természetes dolog, hogy egy számodra fontos cél, egy új munkahely vagy vágyott beosztás elnyerésekor az öröm után megjelenik egyfajta félelem és bizonytalanság is, hogy vajon megfelelően el tudod-e látni az új feladatot. Az új beosztás másfajta készségek és képességek meglétét követeli meg tőled. Nem csak akkor terhel a nyomás, ha szakmát váltasz, és a programozás még új neked, de akkor is, ha feljebb szeretnél lépni a ranglétrán, hiszen más nézőpontot igényel egy csapat tagjaként és mást egy csapat irányítójaként részt venni egy projektben.

Elméleti háttér

“Bármely szervezetben az alkalmazott előbb-utóbb eljut abba a pozícióba, amelynek betöltésére alkalmas, majd biztosan előléptetik egy olyan pozícióba, amelynek ellátása meghaladja a képességeit.” – dr. Laurence J. Peter

Légy te a kivétel, akire nem vonatkozik a Peter – elv!

A Peter-elv (ami Laurence J. Peter után kapta a nevét) annyit mond, hogy az előléptetéseket sokszor aszerint osztják ki, hogy az adott személy hogyan dolgozott jelenlegi pozíciójában, és nem aszerint, hogy a következőre készségei alapján alkalmas-e. Ennek köszönhetően előbb-utóbb mindenki eljut abba a pozícióba, amire már inkompetens lesz, nem fejlődik eléggé, vagy nem alkalmas rá.

Hogyan tudod ezt kikerülni? Egyrészt önismerettel, hogy nemet tudj mondani azokra az ajánlatokra, amelyek ugyan nagyobb fizetéssel, vonzó kiegészítésekkel, hangzatos névvel vagy még többel kecsegtetnek, de a személyiségedhez, értékrendedhez, egyéni preferenciáidhoz nem illeszkednek, ezáltal hosszú távon boldogtalanná vagy sikertelenné tesznek majd. Másrészt felkészülhetsz folyamatos önfejlesztéssel, változtatással és változással, hogy a végül elfogadott pozícióban kihozhasd magadból a maximumot.

Miért kell ehhez coaching, ha vannak barátaid?

Azt, hogy szakmai konzultációkra szükséged lehet, kézenfekvőbbnek tűnhet, mint az, hogy miért hasznos emellé a coaching is, hiszen vannak barátaid, van családod, aki támogat és meghallgat. Ezt a gyakran ismételt kérdést szeretném most megválaszolni neked.

Már azzal, hogy kimondod, ami foglalkoztat, elmondod valakinek, ami történt a munkahelyeden, csökken a stressz szintje. Tudat alatt ezért is alkalmazzuk a panaszkodást olyan gyakran a mindennapi életünkben, mert instant lehetőséget biztosít a bennünk felgyülemlett negatív érzések csökkentésére, különösen, ha a hallgató fél sajnál minket és egyetért velünk. Miért hasznos a coaching beszélgetés, ahelyett, hogy otthon adnád ki magadból a feszültséget? A munkahelyváltás már önmagában nyomás alá helyezi a családi életet és a párkapcsolatot, az állandóan „hazavitt” munkahelyi feszültség ezt a nyomást csak tovább növeli. Eleinte még türelmes a környezet, de a hónapokig tartó panaszkodás arról, hogy melyik munkatárssal van problémád, vagy milyen szakmai kérdésekre nem találod a megoldást, konfliktus forrása lehet, nem csak a családi, de a baráti kapcsolataidban is. Ki szeretné olyan ember társaságában eltölteni a szabad idejét, aki másról sem tud beszélni, mint az új beosztásával járó nehézségekről, vagy ami talán még rosszabb, meg sem szólal, szinte jelen sincs, mert máshol járnak a gondolatai? Végül a megromlott hangulatért egyenesen a munka, a munkahely, a főnököd vagy a személyes alkalmatlanságod lesz a felelős, kinek-kinek vérmérséklete és önbizalma szerint. Ezért szeretnénk a szakmai konzultációkon túl privát business coaching alkalmakkal is megkönnyíteni neked ezt az időszakot. (A munka és magánélet egyensúlyáról az A&K Magazin szeptember 4-én megjelenő őszi számában olvashatsz majd részletesebben.)

90 napos támogatás az A&K Akadémián

Az Akadémiánkon elérhető első 90 nap szakmai és coaching támogatás nem csak segít csökkenteni a stresszt, gyorsabban alkalmazkodni a kihívásokhoz, de védi is a magánéletedben kialakított egyensúlyt. A munkahelyen felmerülő kérdéseket nálunk szakmai közegben vitathatod meg, és hazaérkezéskor magad mögött hagyhatod a nehézségeket, hogy teljes figyelmeddel a szeretteid felé fordulhass.

Ha nálunk végzel, akkor nem kell attól tartanod, hogy támogatás nélkül kerülsz idegen környezetbe, és végül megbánod a változtatást. Melletted állunk és támogatunk, hogy az elméletben elért siker a gyakorlatban is megvalósuljon!

Forrás: Komócsin Laura – Módszertani kézikönyv coachoknak és coachingszemléletű vezetőknek (2011.)
Ha tetszett, oszd meg!

Java 9 újdonságai – 3. rész

Java 9 linkelés

A Java 9 újdonságai cikksorozat előző részében a Java platform modul rendszeréről olvashattál. Ez az új feature lehetővé teszi alkalmazásaink különböző módokon való telepítését. A Java 9 linkelés új, opcionális statikus linkelési lépést épít be a programunk fordítási lépései közé. De kezdjük az elején!

Java 8 kompakt profilok

Ahhoz, hogy megértsük, milyen új képességekre teszünk szert a Java 9 kibővült eszközkészletével, előbb érdemes megnéznünk az előzményeket.

A Java 8 2014. március 18-án jelent meg, és rengeteg várva várt új nyelvi elemet tartalmazott. A legismertebb talán a funkcionális programozást egyszerűbb formában lehetővé tevő lambda kifejezések és a Stream API volt, de számos más újítás is ezzel a verzióval jelent meg. Ezek egyike volt a kompakt profilok bevezetése (compact profiles).

3 kompakt profilt definiáltak, amelyeknek mérhetetlenül izgalmas neveket adtak:

  • compact1
  • compact2
  • compact3

Java 8 előtt

A Java 8 előtt, amikor lefordítottuk a programunkat, nem volt lehetőségünk megadni a Java fordítónak (javac), hogy ne a Java futtatókörnyezet (JRE) teljes eszközkészletére fordítson, hanem annak csak egy részhalmazára. Ez mondjuk asztali számítógépek esetén ma már nem olyan nagy gond, mert itt bőséges memória áll rendelkezésre, viszont ha a mobil eszközökre gondolunk, már más a helyzet. Itt erősen korlátozottak az erőforrásaink. Nem csak a memória, de a processzor, tárhely, hálózati kapcsolat, akkumulátor is. Ezekre az eszközökre nem lenne célszerű a folyamatosan növekvő teljes JRE-t telepíteni, főleg, ha ki sem használjuk annak képességeit.

Java 8 után

A Java 8-ban viszont már megadhattuk a programunk fordításakor valamelyik kompakt profil nevét, ami a teljes Java futtatókörnyezetnek csak valamilyen részhalmazát tartalmazta. A kompakt profilok kibővítik egymást. A legszűkebb részhalmaz a compact1. A compact2 profil tartalmaz mindent, amit a compact1 és egyéb csomagokat is. Ugyanígy a compact3 tartalmazza a teljes compact2-t és egyéb package-eket is. Hogy melyik profil pontosan mit tartalmaz, azt az alábbi táblázatban láthatod:

compact1compact2compact3Teljes JRE SE
Core (java.lang.*)JDBCSecurity (kerberos, acl, sasl)Beans
SecurityRMIJMXInput Methods
SerializationXML JAXPJNDIIDL
NetworkingXML JAXP (adds crypto)Preferences
Ref ObjectsManagementAccessibility
Regular ExpressionsInstrumentationPrint Service
Data and TimeRMI-IIOP
Input / OutputCORBA
CollectionsJava 2D
LoggingSound
ConcurrencySwing
ReflectionAWT
JARDrag and Drop
ZIPImage IO
VersioningJAX-WS
Internationalization (I18N)
JNI
Override Mechanism
Extension Mechanism
Scripting

Megtakarított tárhely

Hogy legyen egy valós képünk arról, hogy mennyi tárhelyet is takaríthatunk meg a kompakt profilokkal, íme egy rövid mérés:

  • compact1 profil: ~14 MB
  • compact2 profil: ~18 MB
  • compact3 profil: ~21 MB
  • Teljes JRE (Java SE Embedded): ~45 MB

Jól látható, hogy a compact1 profil az amúgy is tárhelyoptimalizált teljes Java SE Embedded kiadás egyharmada csupán.
A kompakt profilok már sokat segítettek a problémán, de még mindig nem jelentettek végleges megoldást.

Java 9 linkelés – linkelési idő

A Java 9 linkelés szemléltetésére szolgáló lánc ábraNéha úgy érzem kár lefordítani magyarra a fontosabb angol szakkifejezéseket. Talán most is jobban tettem volna, ha link time-nak hagyom.

Eddig fordítási időről (compile time) és futási időről (run time) beszélhettünk programjaink kapcsán, amik a szoftverünk életciklusának két különböző fázisa. E kettő közé a Java 9-ben beférkőzött a linkelési idő (link time). A Java nyelv a kezdetektől fogva egy dinamikusan linkelő nyelv volt, vagyis amikor a forráskódot lefordítottuk bájtkódra, akkor csak a külső library-kra való hivatkozások neve került a lefordított gépi kódba. A függőségek a program futtatásakor töltődtek be. Ez lehetővé tette, hogy több Java program is használja ugyanazt a külső library-t.

A dinamikus linkelés mechanizmusában semmi nem változott, ez továbbra is így működik. Amivel a Java 9-ben most már többet tud a nyelv, az az, hogy lehetőségünk van egy opcionális statikus linkelési lépést is beépíteni a programunk életciklusába. Ez a linkelési idő, ami a fordítási idő és futási idő között van, egy statikus linkelési lépés. A statikus linkelés során modulok halmazait és azok tranzitív függőségeit (transitive dependencies) tudjuk linkelni, hogy egy run-time image-et létrehozzunk.

Java 9 linkelés – jlink parancssori eszköz

Mindezt a jlink nevű új, parancssori eszközzel tehetjük meg, az alább demonstrált módon:

 

  • module-path: Ezzel a kapcsolóval specifikálhatjuk a JDK moduljainak elérési útját. Ezek lehetnek JAR fájlok, jmod fájlok (a JDK 9 új fájlformátuma, ami hasonló a JAR fájlokhoz, de tud kezelni natív kódot és java konfigurációs fájlokat is) vagy exploded modulok.
  • add-modules: Modulok, amikre a run-time image-et le szeretnénk generáltatni.
  • limit-modules: Korlátozhatjuk a linkelést csak azokra a modulokra, amikre az alkalmazásunknak mindenképp szüksége van. Néha, amikor modulokat adunk hozzá, akkor azok tranzitív függőségeit is hozzáadjuk. Ezzel a kapcsolóval limitálhatjuk, hogy melyek ezek a modulok.
  • output: A kimeneti elérési út, ahova a generált run-time image kerül.

Konklúzió

Láthatjuk, hogy a Java 9 új, jlink parancssori eszközével a modularizált Java programokat új módokon tudjuk telepíteni, ami számos helyzetben jól jöhet. Annak köszönhetően, hogy a Java 9-ben maga a core csomagok is modularizálva lettek, ha saját projektünket is modularizálva írjuk meg és modularizált külső library-kat használunk, akkor olyan run-time image elkészítése válik lehetővé, ami a korábbi verziókban nem volt kivitelezhető.

Ha többet szeretnél olvasni a jlink használatáról, akkor azt ezen a hivatalos Oracle oldalon teheted meg.

Ha tetszett, oszd meg!

Java 9 újdonságai – 2. rész

Ez a cikksorozat a Java 9 újdonságait taglalja. Az első részben elkezdtük megnézni, hogy a Java 9 modul rendszere miért annyira fontos, milyen problémát hivatott orvosolni. Lássuk most hát a részleteket!

A Java 9 modul rendszere (Jigsaw)

A dunsztos üvegektől nincs menekvés

A JAR-ok – vagyis Java ARchive-ok ( = dunsztos üveg) – nem mások, mint lefordított Java osztályok, némi metainformációval ellátva, ZIP-re tömörítve és .jar kiterjesztéssel ellátva.

A Java 9 modul rendszere ezt a struktúrát a metainformációk terén egészíti ki. Ezentúl a moduláris JAR fájlok rendelkezni fognak egy modul leíróval (module-info.class). Ebben a leíróban meghatározhatjuk, hogy ez a modul milyen más modultól függ. Ezt a következő szintaxissal tehetjük meg:

A kocsi modulunk függ a motor modultól, vagyis ez a kocsi modul nem működőképes motor modul nélkül. Ezt grafikusan a következőképp ábrázolhatjuk:

Java 9 modul rendszer requires példa

A requires-ön túl van egy másik kulcsszavunk is, amit használhatunk. Ez a kulcsszó az exports, amivel azt adhatjuk meg, hogy a modulunk melyik csomagja (package-e) érhető el egy másik modulból. Minden, amit nem nevezünk meg az exports kulcsszóval, az alapértelmezés szerint nem exportálódik, vagyis rejtve marad más modulok előtt. Ez megoldja a bevezetőben említett potenciális kódelspagettiasodást. Ha kiegészítjük az előbbi példánkat ezzel, akkor ezt kapjuk:

Java 9 modul rendszer exports példa

Mi fog történni a Java core osztályaival?

A jó hír az, hogy ezeket is feldarabolták modulokra, így sokkal könnyebben tudják majd a jövőben kibővíteni. Ez azt is lehetővé teszi, hogy az olyan platformokon, ahol szűkösek az erőforrások – például a mobil alkalmazások – ott az adott platformra fordított kódhoz csak a tényleg szükséges modulokat mellékeljük, ezzel tárhelyet, memóriát, hálózati adatforgalmat, vagy akár akkumulátor energiát is megtakarítva.

Amikor elindítunk egy moduláris Java programot, akkor a requires függőségi lánc mentén a JVM ellenőrzi, hogy minden modul megtalálható-e. Ez sokkal kényelmesebb nekünk, mint a korábbi Java verziókban, amikor a classpath paraméterben az összes függőséget fel kellett kézzel térképeznünk és sorolnunk.

Java modul rendszer konklúzió

kirakó ami a Java 9 modul rendszerét szemléltetiEzen új feature-ök segítségével újonnan írt programjainkban újabb szinten megvalósulhat az OOP egyik alapelve, az egységbezárás (encapsulation), aminek az előnyei régóta jól ismertek.

De mint láthattuk, a JAR-októl nem szabadulunk meg, továbbra is ez lesz a formája a library-k tárolásának, csak kibővítették a leíróképességét, ezzel sok új lehetőséget megnyitva előttünk.

Ebben a blog posztban nem sikerült minden részletre kitérni, mint például a névtelen modulokra illetve az automatikus modulokra. Az említett két kulcsszón kívül vannak még egyebek is, amikkel tovább finomítható a modulok összekapcsolása.

Tanfolyamunkon természetesen gyakorlati példákon keresztül megnézzük a legfontosabb lehetőségeit ennek az új nyelvi elemnek.

Ha szívesen olvasnál még többet a Java 9 modul rendszerről, akkor figyelmedbe ajánlom az angol wiki oldalát.

Ha tetszett, oszd meg!

Java 9 újdonságai – 1. rész

Java 9 megjelenési dátuma

A Java 9 aktuális tervezett kiadási dátuma 2017. szeptember 21. Vagyis itt van a nyakunkon. Elég zűrös Java verzióról van szó, ami a határidőket illeti, ugyanis nem egyszer lett elhalasztva a kiadás dátuma. Ez talán nem is olyan meglepő, ha megnézzük, hogy milyen új feature-ök kerültek bele. Az elkövetkezendő blog posztokban sorra vesszük a leglényegesebb újdonságokat.

Java 9 oktatás az A&K Akadémián

Hogy lehet az, hogy mi már ezt a verziót oktatjuk, amikor még meg sem jelent?

A végleges hivatalos verzió még valóban nem jelent meg, de az early access (EA) verzió már egy ideje elérhető, amely mivel már túl vagyunk a feature complete dátumon, az összes feature-t tartalmazza, ami a végleges verzióban is benne lesz.

Be kell vallanom, hogy nagy mázlista vagy, ha most kezded el a Java-t tanulni, mert az egyik feature – a jshell – nagyban segíti az oktatást és a tanulást, főleg a kezdeti lépéseknél, mert nagyon szemléletes eszköz. De erről részletesen majd egy kicsit később. Először akadna itt egy kis játék…

A Java Platform modul rendszere (Jigsaw) – bevezető

Java 9 - Project JigsawA Java 9 legmeghatározóbb eleme a Project Jigsaw néven futó, a Java modularizációját célzó projekt, amely a többszöri release date csúsztatásért felelős.

Én személy szerint nem bánom, sőt, örülök is neki, hogy a projekt fejlesztése során tartott mérföldköveknél őszintén képesek voltak a projekt aktuális állapotára objektíven tekinteni, és azt mondani, hogy ez így nem elég jó.

Mint tudjuk, a Java nyelvnél erősen koncentrálnak a készítők a visszafele kompatibilitásra, vagyis hogy az új Java verziók, amennyire csak lehet, a korábbi verzióval fordított bájtkódot módosítás nélkül futtatni tudják. Persze ez nem volt mindig tartható.

A modularizáció megoldása a Java nyelv jövőjét tekintve esszenciális feladat. Ami most a Java 9-ben a nyelv részévé válik, az ezentúl mindig szerves részét fogja képezni, radikális módosítások eszközölése jelentős problémákat vetne fel. De úgy tűnik, hogy most már hamarosan tényleg lezárják ezt az alprojektet és az éles kiadás részét fogja képezni.

Miről is szól a Java Platform modul rendszere?

Eddig is volt lehetőség megírt kódunk alap szintű szervezésére. Ha arra gondolunk, hogy megírt osztályainkat már most is külön fájlokban tároljuk, illetve ezeket a fájlokat tudjuk csoportosítani mappákba, vagyis csomagokba (package-ekbe).

A modul rendszer lényege, hogy még egy absztrakciós szinttel kiegészítse ezt a csoportosítás.

Miért jó nekünk még egy absztrakciós szint?

Az alapvető probléma a Java nyelv hozzáférés módosítók limitált képességeiből adódik. Mindannyian ismerjük a public, protected, private és package private scope-okat. A public elérhetőségű osztályaink jelentik itt a problémát, ezek publikus metódusai ugyanis a publikus API-nk részét képezik, és ezáltal bármilyen más osztályból elérhetők. Ez a Java nyelv létrejötte óta hatalmas gubancokat okozott már a komplex rendszereknél, ugyanis amit a nyelv megenged, azt bizony a leleményes programozók ki is használják. Így történt ez ennél a nyelvi feature-nél is, ami átláthatatlan, szövevényes, spagetti kódot eredményezett. A spagetti kódnak súlyos hátrányai vannak.

JAR – JAR

A Java 9 előtt lényegében az egyetlen módszerünk az enkapszulációra a JAR-ok voltak. A JAR – vagyis Java ARchive – a programunk lefordított változatának egy ZIP fájlba tömörített változata, amit néhány metainformációval elláthattunk, mint például, hogy melyik osztály main metódusa a belépési pont. Ha például Java-ban JSON adatstruktúrákat szerettünk volna használni, akkor letöltöttük a megfelelő JAR fájlt, amiben minden osztály benne volt a JSON-ök kezeléséhez. Természetesen kedvünkre választhattunk az implementációk közül, mert több csapat is fejleszt saját JSON kezelőt.

Ezek után persze a programunk már csak ezen JSON kezelő JAR jelenlétében működőképes, amikor kiadjuk éles rendszerünket, akkor ezt a JAR-t se szabad elfelejtenünk.

Érdekesség

A „jar” egy angol főnév is, ami többek között dunsztos üveget jelent, amiben a lekvárt is eltesszük. A JAR elnevezés valószínűleg innen is kapta a nevét, csak mi nem lekvárt, hanem lefordított Java osztályokat teszünk el benne.

Dunsztos üvegek… dunsztos üvegek mindenütt!

Egy nagy rendszer esetén természetesen nem csak egy ilyen külső library-tól való függőségünk van, hanem több, illetve tovább bonyolítja a helyzetet, hogy egy külső library maga is lehet, hogy egy másik library-t igényel a működéséhez. Ezeket a függőségeket, más szóval dependenciákat, feloldani sokszor nem triviális feladat.

Eddig mi tévők lehettünk a JAR-ok támadása ellen?

Ennek kezelésére eddig a modern build toolok adtak elegáns megoldást, mint a Maven és a Gradle. Ezeknél a tooloknál ugyanis egy központi repository-ban számon tartják az összes publikus library (artifact) összes publikusan elérhető verzióját azok függőségeivel együtt. Ez lehetőséget biztosít számunka a build tool használata során, hogy csak azt tüntessük fel, hogy a mi aktuális projektünknek milyen külső library-kra van szüksége, és a dependenciák feloldását már maga a tool végezze. Ez azt jelenti, hogy ha például a JSON kezelő library függ egy dátum kezelő library-tól, akkor ha mi a saját projektünknél megjelöljük, hogy a JSON kezelő library-ra szükségünk van, akkor a tool automatikusan felderíti a függőségi láncolatot és feloldja a függőségeket, vagyis ebben az esetben letölti a projektünkhöz a dátum kezelő library-t is, ezzel működőképessé téve a projektünket. A JAR-ok önmagukban ezt a függőséget nem képesek kifejezni.

Ezt a súlyos problémát orvosolja a Java Platform modul rendszere, amelyről a következő blog posztban olvashatsz.

Ha tetszett, oszd meg!