Előfordul, hogy az egyik metódusból értéket kell átadnunk egy másik metódusnak anélkül, hogy azt paraméterként adnánk át. Lehet ez amiatt, mert a két metódus között nincs közvetlen hívás, és nincs ráhatásunk a közbülső metódusokra.

Ilyen lehet pl. a bejelentkezett felhasználó, a tranzakció, vagy a log MDC. Ezeket gyakran környezetnek (contextnek) nevezik, pl. Security Context, Transaction Context, Mapped Diagnostic Context.

Másképp kell ezt megoldani Servlet API-ra épülő megoldásnál (ThreadLocal), pl. Spring MVC-nél, és máshogy reaktív módon, pl. a Project Reactorra épülő Spring WebFlux esetén (context). Sőt, a 25-ös Javaban megjelent a ScopedValue osztály a ThreadLocal osztály kiváltására.

A poszthoz tartozó példaprogram elérhető a GitHubon.

A poszt még két videót tartalmaz.

Figyelem! A poszt nem AI-jal készült!

Talán minden ott kezdődött, mikor az első Linux kernelt fordítottam egy 486-os PC-n. A számítógéphez egy betárcsázós modem volt kötve, és a sötét szobában néztem, ahogy a konzolon szaladnak végig a számomra érthetetlen sorok. Persze elhasalt. Majd újra elhasalt. De maradandó élmény volt, mikor hiba nélkül végigfutott, és használatba vehettem az első saját kernelemet. (Azt ígérték, gyorsabb lesz, hittem is, hogy gyorsabb, de valójában nem volt az.)

Az egyetemen a gépteremben VAX/VMS-t használtunk, távoli terminállal, konzolos böngészővel és levelező programmal. Fordítottam rajta Java forráskódot is. Percekig. Az asztali gépbe be volt dugva a külső winchester keret, benne a saját disk, mi csak úgy hívtuk, rack. FTP-vel másoltam rá az MP3-akat az Internetről.

Második munkahelyemen mondták: “Ha megírtad a programod, telepítsd is fel. Itt egy SSH elérés.” Linux, JDK 1.4, Tomcat, 2008-at írunk. Ekkor még nem létezett a szó, DevOps.

Később, mikor már komolyabb rendszerek fejlesztésében vettem részt, többször megfordultam nagyobb szervertermekben. Egyszer bementünk a BIX-be, a Victor Hugo utcában. Mindig elvarázsoltak az embernyi rack szekrények, rajta a villogó ledek, a deréknyi kötegek UTP kábelekből, és az RJ45 csatlakozó jellegzetes kattanása.

Érdekes, gépet építeni sosem szerettem. Nem szerettem a SATA kábeleket, a PCI csatlakozókat, az elgörbült CPU lábakat, a pasztázást, a jumpereket.

Hálózatok 1 tantárgy teljesítéshez kötelező olvasmány volt a Tanenbaum-féle Számítógép-hálózatok könyv. Nem varázsolt el. Most már igen, meg kellett rá érni.

Mikor megjelent a Raspberry Pi, azonnal rendeltem. Sokáig a fiókban volt, de ma már folyamatosan megy.

Ma a YouTube-on előszeretettel nézem azokat a timelaps videókat, ahol egy kábeldzsungelből egy rendezett szervertermet varázsolnak. Ahol lelkes kollégák saját labor környezeteket (home hab) alakítanak ki, vagy egymás megoldásaira reagálnak. (Párat meg is fogok osztani.)

Eljött az idő, hogy én is kialakítsam az otthoni hálózatomat, és labor környezetemet.

Cloudban egy viszonylag kevés erőforrással rendelkező virtuális gépen futtatok egy Spring Boot alkalmazást. (Ez amúgy a Learn web services oldalamhoz készült példa alkalmazás, mely CXF keretrendszerrel SOAP-os webszolgáltatást biztosít.) Sajnos többször elfogyott a memória, így választhattam, hogy vagy natív binárist készítek belőle, és bízom benne, hogy kevesebb memóriát foglal, vagy váltok egy erősebb gépre.

Gondoltam itt az alkalom, hogy élesben kipróbáljam, hogy mit nyújt a GraalVM, beváltja-e a hozzá fűzött reményeket. Külön érdekelt, hogy lesz-e gond a CXF keretrendszerrel, melynek nincs GraalVM támogatása. Már most elárulom, a natív bináris hetek óta fut gond nélkül.

A NETAcademia (, mely mögött a Training360 áll) NETA.live néven egy új, ingyenes előadássorozattal jelentkezik.

Az első online webináron 2025. október 29-én 18:00-kor a Spring AI-ról fogok előadást tartani. Nem a hype-ot akarom tovább duzzasztani, hanem élő kódolás közben bemutatni a Spring AI lehetőségeit, azaz hogyan lehet LLM-hez kapcsolódni, RAG technikát alkalmazni, vagy egy MCP szervert fejleszteni, amit aztán agentek tudnak felhasználni.

Az esemény alapvetően olyan Java fejlesztőknek szól, akik szeretnének megismerkedni a Spring AI képességeivel.

Regisztrálj az esemény oldalán, és kapcsolódj be te is a YouTube élő közvetítésbe, ahol kérdéseket is feltehetsz! Ha nem érsz rá, de regisztrálsz, akkor később is visszanézheted a felvételt.

A Behavior-Driven Development (röviden BDD) már egy 2000-es évek elejétől létező módszer. Még a mai napig is sokan használják, sőt vezetik be létező vagy új projekteken.

Sajnos azonban azt vettem észre, hogy sokan félreértik és hibásan használják. Az Interneten is rengeteg rossz példa terjed, sőt a különböző nagy nyelvi modellek is hibás megoldásokat hoznak (nyilván az előbbi példák alapján), ezekből is fogok többet is mutatni. Ezzel azonban nem segíti, hanem inkább hátráltatja a projekt előrehaladását.

Ebben a posztomban megpróbálom összegyűjteni, hogy hol lehet elrontani a BDD használatát, valamint milyen rossz gyakorlatokat látok a mai napig. Saját tapasztalatokat és erősen szubjektív elemeket is tartalmaz. Ez a korábbi Fejlesztőként mivel akadályozom a tesztelők munkáját? írásom folytatásaként is felfogható.