Toplink bug II.

Újabb szép Toplink Essentials bug vett el egy (eddig) egy napot a projektünkből. Prototípus projektet még nem sikerült csinálni, de jól reprodukálható, és ismét a leszármaztotott osztályok mint entitások körül van a gikszer, csak most a belső cache táján. A szépségét jól jelzi az, hogy ha a tesztelés két lépése között újraindítom a Glassfish-t, akkor minden megy, ha nem, akkor OptimisticLocking exceptiont kapok. Előtte mg utána csak persiste és find-van, de a find hol a szülő, hogy a gyerek entitásra keres rá.

A workaround egyelőre a Toplink level 2 cache-nek kikapcsolása:

<property name="eclipselink.cache.shared.default" value="false"/>

De most épp valami hasonló hiba néz ki a kódból, amit még nem derítettünk fel, úgyhogy lehet, hogy ez se segít. Egyébként EclipseLinke M7-tel a helyzett ugyanez. Lehet, hogy Hibernate JPA-val is ki kéne próbálni, de az meg a kissé bonyolult entitás struktúránkba hal bele (Bizonyos dolgokat annotációval, másokat XML-ből állítunk be).

WTF: Interface Equinox módra

Sajnos az OSGi nem tartalmaz szabványos interface-t a konzol szolgáltatásokra. Konzolja azonban szinte minden OSGi frameworknek van, és általában ezeket valahogy ki is lehet terjeszteni, hogy saját parancsaiddal bővítsd a rendszert.

A Felix-ben pl. a SehllSerivce-t kell implementálni:

public interface ShellService
{
    public String[] getCommands();
    public String getCommandUsage(String name);
    public String getCommandDescription(String name);
    public ServiceReference getCommandReference(String name);
    public void executeCommand(
        String commandLine, PrintStream out, PrintStream err)
        throws Exception;
}

Ez a dokumentáció nélkül is körülbelül érhető. De hogy csinálja mindezt az Equinox?

Nos előszőr is implementálni kell egy CommandProvider interface-t. Ezek után pedig minden metódus, ahol a metódusnév _-al (aláhúzással) kezdődik automatikusa a konzolból is elérhető parancs lesz. Az én konzervatív OOP-s lelkemnek ez már határeset.
Jó, jó, legyen egyszerű, de nem gányolás ez kicsit?

Java PDF2HTML

A mai nap egy régi XSL-FO-s rendszert kellett volna újraéleszteni az új környezetbe, hogy HTML-t PDF-en keresztül tegyünk szépen nyomtathatóvá.

Biztos ami biztos előtte azért körbenéztem, és azt találtam, hogy létezik egyszerűbb megoldás is. Pl. az xhtmlrenderer pont tudja ezt iText-en keresztül.

Van hozzá egy jó részletes cikk, és azt kell mondanom, hogy tényleg működik. A prototípus probléma nélkül csinálja a dolgát (pedig még némi iText varázslattal meg van bonyolítva).

Szóval eddig jó, remélem a UseCase-ek implementálása közben is ugyanilyen elégedett leszek.

JUM számvetés

Egyéves a JUM: hazánk leg Java User Group-osabb Javas rendezvénysorozata. Egy év alatt hat alkalom, 21 előadás (ha jól számoltam): a mérleg pozitív. A továbbiakhoz azonban nekem mindeképp igényem lenne egy számvetésre, hogy hol mit kéne jobban csinálni. Vitaindítónak az alábbiakban foglalom össze saját észrevételeimet.

Helyszín: erre szerintem nem lehet panasz. Krisztiánnak sikerült mindig előre pontosan mindent elintézni, csak újfent megköszönni lehet a Sztakinak a támogatást.

Lebonyolítás: itt már van mit javítani. Szerintem nagyon hiányzott alkalmanként egy moderátor aki:

1. elmondja az elején a napirendet
2. utána betartatja (ne legyen túl hosszú szünet, esetleg ne legyen egyáltalán, maradjon feszes a program)
3. Az előadásokat is moderálja, leállítja, ha nagyon túlfut az időből stb.

Valahogy úgy alakult, hogy ilyen nem volt (eleinte aki csinálhatott volna ilyet, az elő is adott, később meg nem alakult ki). Szerintem szükség volna rá, akár úgy is, hogy minden alkalommal más válalja el.

Az hogy beálltunk a kéthavonta fix időpontra az mindenképpen okos dolog volt.

Előadások: ez szerintem az egyik legfontosabb kérdés. Az eredeti elképzelés valami unconference jellegű dolog volt, ahol:

1. mindenki előadhat, aki jelentkezik
2. hangsúlyosan saját tapasztalatokról kell beszélni (vér, verejték, izzadság)

Sajnos azonban a rendszer nem vált be teljesen. Egyrészt nehéz volt jelentkezőt találni. Aztán kiderült az is, hogy ha valakinek komoly tapasztalata van egy témában, az még nem biztos, hogy jól el is tudja mondani azt. Néha még az is eszembe jut, hogy olyan emberből akit én elképzeltem, talán nincs is olyan sok.

A legfontosabb szerintem amin változtatni kell az az előadásól színvonala. Bármit is jaívtunk a többi pontnál, ha nincsenek színvonalas/profi előadásaink, akkor nem érdemes csinálni. Nem érdemes közönséget szerezni, stb.

Több út is van:

1. A JUG-ok szerte a világban általában egy hosszabb meghívott előadóval dolgoznak alkalmanként.
2. A mi eredeti célkitűzésünkhez, ami sokkal inkább unconference jellegű volt, jobban passzol a több rövidebb előadás.
3. Ennek a másik oldala a Meetup jellegű tízperces előadás, ami bizonyos esetekben adekvát lehet (ezt Kocka próbálta megjeleníteni), de egy ismeretlen technológia előnyeit, hátrányait, és a róla szerzett tapasztaltokat, szerintem nem lehet hatékonyan tíz perc alatt elmondani.

Nem látom igazán még megfelelő módszert. Volt olyan ötletem is, hogy a résztvevői, bemutató előadásokhoz kötelező legyen prototípust csinálni (Kocka legjobb előadása szerintem a legutóbbi Flex-es volt, amihez már előzőleg publikálta a prototípust). Ha van prototípus, sokkal könnyebb bemutatni, az egy biztos vezérfonal. De létezhetnek olyan elméletibb témák, amihez lehetetlen prototípust csinálni.

Szerintem azt is jó lenne, hogy ha megkeresnénk azokat a magyar fejlesztőket, akik nemzetközi OS projektekben dolgoznak, és őket meghívnánk, hogy beszéljenek a saját projektjükről (meglepően sok ilyen van).

Lehetne esetleg valami szavazás/feedback-et csinálni alkalmanként, de ha mondjuk a 20 résztvevő harmada kitölt egy kérdőívet, az már nem biztos, hogy számottevő minta.

(Itt azért megjegyezném, hogy voltak nagyon jó előadások is, és talán nem volt olyan alkalom, hogy ne lett volna olyan, ami miatt ne lett volna érdemes elmennem, de ez, úgy érzem, még kevés).

Infrastruktúra: A másik olyan pont, amit nem kezeltünk elég jól. Van egy honlap (jum.hu), de nem mindig frissült elég gyorsan. Van rajta hírlevlél, ami nem mindig ment ki időben. A fóliákat nem szedtük össze, a videók bár elkészültek, nem kerültek fel sehová, stb. Ezeken mindenképpen változtatni kell.

Marketing: Eddig azt hiszem javaforum-on, és a java listán volt hirdetve, és így körülbelül 15-20 ember jött el egy alkalomra (ritkán több, néha kevesebb). Kérdés, hogy fontos-e, hogy többen legyünk, kell-e a hirdetésre nagyobb energiákat fektetni.

• Egyrészt, ha a tapasztalatok megosztását önmagában hasznosnak tartjuk, akkor elvileg ha csak öten vagyunk az is jó.
• Másrészt ha akarunk hívni meghívott előadókat, akkor illik legalább valamennyi közönséget prezentálni. (Ajánlkozott előadó külföldről is, de 20 ember miatt talán kicsit túlzás idehívni).

Itt is lehetnek ötletek, pl. a Java fejlesztő bázissal rendelkező cégek vagy egyetemek megkeresése.

A javaslat: A következő alkalom (május 21) nem lennének Java-s előadások (itt nem részletezett szervezési okok miatt se), hanem helyette a fenti témákról lenne egy hogyantovább vita/beszélgetés/ötletelés. Ezt ugyanúgy meghirdetnénk, mint bármelyik más alkalmat (mindenki jöjjön, akit érdekel egy kicsit is a rendezvény/egy működő magyar JUG jövője). Viszont most vissza kell jelezni, mert a létszám függvényében szerzünk termet. Ha kevesen vagyunk, akkor esetleg vendéglátó ipari egység is szóbe kerül, de ott is az elején szigorú napirend szerinti megbeszélést tartunk a jövő évről. Tehát aki jönne, az íron egy levelet az info kukac jum pont hu-ra, és jövő hét elején kitaláljuk a helyszínt.

További OSGi tapasztalatok

OSGi-val való további ismerkedés keretében csináltam egy remek Jabber / XMPP OSGI kozol bundle-t. A lényege, hogy nem csak op rendsze parancssorából indított OSGi framework konzoljából pásztorolhatjuk a framework konzolját, hanem Jabberen keresztül is. (Bundle-k listázása, leállítása, stb.)

Egy érdekes dolog, hogy konzolos parancsokhoz nincs szabványos OSGi interface, ezért az összes framework külön talált rá megoldást (én eddig a Felix és az Equinox alá implementáltam a bundlet). Ebben az a szép, hogy a pluginem kódja, az Equinox és a Felix bizonyos osztályaitól is függ fordítás szinten, de futás szinten csak akkor fog ráfutni olyan kódra, ahol Felix specifikus osztályokat használok, ha létezik olyan beregisztrált service (a servicek String névre vannak regisztrálva, a létezés az osztály nélkül is ellenőrizhető). Azt kell mondjam, az OSGi koncepció működik.

Fejlesztéshez a pax-construct maven plugint használtam (Ami használja a Felix bundle plugin-t is). Viszonylag kis szívás volt vele, csak egyszer kezdtem el debugolni, de akkor is kiderült, hogy felesleges volt, a Felix bundle dokumentációját kellett volna jobban átnyálazni. A fenti Classloader-es trükhöz kell ugyanis finomhangolt Import-Package leírót gyártatni, hogy a framework függőségek csak opcionálisak legyenek.

(Zárójeles megjegyzés: amilyen csapnivaló volt a NetBeans 6.1 Beta Maven pluginje, a végleges annyira meggyőző. Pl. most már olyat is tud, hogy ha egy ismeretlen osztályt lát, akkor egy klikkre felajánlja a központi repository-ból azokat az artifactokat, amik tartalmaznak ilyen nevű osztályokat. És mivel már a Glassfish 3 TP és az OpenESB 3 fejlesztés is Maven-be megy, úgy hogy a NetBeans Maven támogatás csak jobb lesz ennél.)

Szóval jó kis játék volt, lehet hogy feltolom Google Code alá. Szinte ugyanannyi ott projektet létrehozni, mint a saját szerveren belőni SVN-t.

Testablility Explorer

A testability explorer (nem meglepő módon) egy kód tesztelhetőségét hivatott vizsgálni. Van egy publikus demó oldal is, ahol néhány OS projekt tesztelhetőségét publikálják. (pl. itt az ANT 1.7-é).

Első látásra teljesen elvarászolt, de aztán kiderült, hogy igazából semmi új, csak a Cyclomatic Compexity-t viszgálja, plusz az írható globális mezők értékét (Counts the number of fields which are globally reachable by the class under test and which are mutable.)

A Cyclomatic Compexity egy mérőszám, ami megmondja, hogy mennyi különböző lefutása lehet egy metódusnak. Ha pl. van benne egy darab if, ami vagy igen vagy nem, az már két lefutás. Minnél több lefutása lehetséges, annál nehezebb tesztelni. Nem nagy truváj, a PMD is mér ilyet. Most már inkább az érdekel, hogy hogy méri mindezt az ASM segítségével. Ha lesz időm játszanom kell majd vele egy kicsit.

(Via: Az eszközre Alex Miller bejegyzésén keresztül találtam rá amit Eugene Kuleshov BOF sessionjéről írt. )

Java One messziről

Nem tudom miért pont idén, de valahogy a JavaOne résztvevői most kattantak rá a Twitterre, és jó nagy zajjal tudósítanak is róla. Már maga az vicces, hogy ilyen commenteket olvashatok:

(stevegio): I think I'm going to avoid all javaone sessions whose descriptions begin with the letters 'JSR'

De persze a legértékesebbek a linkek, már vagy 3-4 jó independent Java blogot találtam, meg pl. egy Java-ba írt Quake implementációt.

Amúgy az még nem jött le, hogy lett volna nagy bejelentés. Állítólag ugyan van JavaFX roadmap, de még nem találtam meg.

UPDATE: Google bácsi kisegített.
Sun set forth a road map for JavaFX:

* In July, Sun will open the JavaFX Desktop SDK Early Access Program
* In the fall, JavaFX Desktop 1.0 ships.
* In the spring of 2009, the JavaFX Mobile and TV 1.0 variants will ship.