Végre, beadtuk. Az UML tárgyból esedékes házi feladatot (lásd még [[J2EE – a nagy aknamező|a múltkori írást]]). Ez J2EE egyszerűen valami félelmetes. Ez a technológia szép. De tényleg…
Az implementáció után mindössze teszteseteket kellett írni az utolsó beadásra. Mindössze. Persze ez akkor sem olyan egyszerű, hiszen azt JUnitban kellett megírni, ami alapvetően maga szeretné futtatni a teszteket. Semmi gond, akkor átverjük, feltöltjük a JUnitot is a konténerbe, és ott majd látni fogja a keresett dolgokat.
Hehe, már megint optimista vagyok ezekkel a cuccokkal kapcsolatban. Ez, hogy feltöltsük a JUnitot, ez körülbelül két óra szívást jelentett a classpath, build path, referenced projects, requirements és hasonló témában projektek és pluginek viszonylatában. Ezek tulajdonképpen mind-mind egyfajta függőséget jelentenek a projektek és más projektek, esetleg libek vagy hasonlók között, de az a poén az egészben, hogy a szerepük között jelentős átfedések vannak. És ami igazán kellemetlen az az, hogy ha a helyes megoldás mellett egy nem szükséges helyen megadod a függőséget, akkor már nem jó. Lehet vele szépen játszadozni.
Jó, túl vagyunk az alapozáson, megvan a teszt keretrendszer, kezdünk teszteseteket írni. Egyszer csak egyik kolléga megkeres, hogy nagyon eszement hibaüzenetet ad egy importra: nem azt, hogy nem találja, hanem azt, hogy nem engedélyezett a használata. Remek, újabb szép körnek néz ki. Ezúttal sajnos nem tévedtem. Némi játszadozás után értettem meg, hogy tényleg látja, csak valami miatt nem akarja használni. Közben szétvertem a tesztkörnyezetet (utána újból órákba kerül, amíg mindenkinél összeáll, de erről később). Na, ekkor némi Google, meg váltogatás a különböző Eclipse környezeteim között (bizony, nekem több is van, be-be-be 🙂 ), és kiderül, hogy a probléma egészen csúnya: az Eclipse támogat egy package-korlátozást (access rule-nak hívja) a különböző pluginekre. Ok, ez önmagában nem csúnya, hisz így az Eclipse-plugin írója rákényszerítheti a felhasználó plugint, hogy az api-n keresztül érje el. De ami gáz, hogy ezt alkalmazta a beépített Java típuskönyvtárra.
Ok, módosítsuk a dolgot. Némi segítség után rájövök, hogy melyik jarban van a keresett osztály. Adjunk hozzá egy engedélyező bejegyzést a jarhoz tartozó access rule-ok közé. Újabb pofára esés, és kiderül, hogy nem írható. Remek. További leírásböngészés, és ekkor kiderül, hogy az ősét, ha tudom szerkeszteni, az is jó. Na, azt tudom, mert a globálisat engedi szerkeszteni, csak a system jarokét nem, meg a workspace-ben definiált pluginekét sem (azokat a plugin.xml szerkesztőjén lehet hakkolni). Remek, beírom az osztálynevet com.sun…. formában, örülnék, hogy megy, de nem megy. Ok, nézzünk mintát, igaza van, /-rel kell írni, és ha *-gal zárom, akkor egy package-re lebontva tudom szerepeltetni. Ok, egy részét átírom /-esre (nem kéne azért a teljes com. tartományt engedélyezni), majd csillaggal lezárom. Még mindig nem jó. Aztán kiderült. Ahhoz, hogy rekurzívan elinduljon lefelé a csomaghierarchiában, ahhoz nem árt **-gal lezárni… Na, ezután már megy.
Illetve csak az a hivatkozás. Csak a libekkel szórakozás miatt elment a futtatókörnyezet. Sebaj, rutinos róka vagyok már, nekilátok és összerakom a megfelelő fájlt (jó, most csaltam, összeklikkeltem a run dialogban). Végre megy nálam. Ekkor töltsük fel svn-re, hogy a többieknek is menjen.
Eltelik pár perc, és kiderült, hogy nem ment át. Mint utóbb kiderült, verzió- és oprendszerkülönbségek miatt. Az OSX->Windows irányban nem működik. És fordítva sem. Az lett a vége, hogy a Windows-osok megcsinálták a környezetet, majd feltöltötték svn-re, ezután én is megcsináltam az enyémet, de én nem töltöttem fel. Erre ezután minden commitnál vigyázni kellett remek. Még szerencse, hogy a Java platformfüggetlen.
De ez semmi ahhoz képest, ami ma hajnali 5 magasságában derült ki, 6 órával a beadás előtt (ameddig persze be is kellett érni az egyetemre). Megírtam már 40 tesztesetet – ez majdnem ezer sor kód, ezek segítségével több hibát is kijavítottam a tesztelt kódrészben. De tényleg. Futott minden. Amikor a kolléga közli velem, hogy a teszteseteim egy része meghal, és ez hazavágja az egész adatbázist. Nálam persze semmi ilyesmi. Némi kísérletezés után kiderül, a gond az, hogy a Windows nem eszi meg a megoldást. Pont. Akkor mutassuk be Macen. De Macen meg egyes Windowson megírt tesztesetek nem futnak. 😕
A hibát nem sikerült megoldani… Mindenesetre kezdem azt hinni, hogy olyan, hogy platformfüggetlen nem létezik. A Java legalábbis biztosan nem az. Például az AbevJava máshogy megy Windows-on, mint Linuxon vagy OSX-en. És ez a mostani hiba is megerősíti ezt az elképzelést. Azt, hogy mi lehet a hibás, csak tippelni tudom. Van egy elszúrt (értsd: feleslegesen túlbonyolított) entitáshalmazunk, van egy toplinkünk mysql adatbázishoz csatlakoztatva, van alatta oprendszer, OSGi konténer, stb. stb. stb. Erre már csak Murphyt idézném zárógondolatként:
- A bonyolult rendszerek hajlamosak a bonyolult meghibásodásokra.
- Ezzel szemben az egyszerű rendszerek is hajlamosak a bonyolult meghibásodásokra.
Vannak érdekes szívások java-val (mivel nem?), bár én csak J2SE-vel foglalkoztam eddig (hála az égnek?) és 98%-ban az derült ki, hogy én vagyok a hülye. A maradék 2% sem bizonyítja, hogy nem vagyok az, de legalább nem csak én..
A JUnit meg önmagában is szívat, külső segítség nélkül.
Általánosan igaz, hogy minél több elemből áll egy rendszer, annál több helyen tud elromlani. És mint tudjuk, ami elromolhat, az el is romlik.
B;
Csatlakozom Balage-hoz: szerencsére még én is csak kóstolgattam a J2EE-t, és a J2SE-ről alapvetően azt mondanám, h sok minden jól össze van rakva benne. Noha időnként a saját tervezési elveiknek mondtak ellent az API fejlesztői, és a request for enhancement-eket sokszor nem hajlandók figyelembe venni…
A J2EE és a J2SE két külön világ, el se hittem volna, hogy mennyire, amíg nem próbáltam ki. A J2SE alapvetően egy többé-kevésbé kényelmesen használható rendszer általános célú programozásra, míg a J2EE inkább nagyvállalati rendszerek programozására van kitalálva. Ezen belül pedig nagy szerepe van az adatbáziskapcsolatok magas szintű menedzselésének (pl. olyan magas szintű, hogy a kódban csak egy-egy annotációval jelölöd, hogy ezt le kell menteni bizonyos hívások hatására, és megírod a bizonyos hívásokat), a telepítés leíróknak (amiről J2SE esetén teljesen el lehet feledkezni, behúzod a kívánt könyvtárba és futtatod) és egyéb apróságoknak, amik fontosak lehetnek.
És itt jön be még az is, hogy az Eclipse is nem más, mint egy hatalmas pluginkészlet rengeteg-rengeteg függőséggel, ezt fordítottuk le RAP segítségével AJAX-szal működő weboldallá – ugye nem csak én érzem úgy, hogy hipermegbízható technológiából hipermegbízható technológiára fordítunk béta állapotú konverterrel jó muri?