2008-01-17

JUM V.

Megvolt az ötödik is. Kocka leírta hogy mi volt, az éppen építgetés alatt lévő Javafórumon pedig született egy-két topik a találkozó után. Egyik a JasperReports-ról, másik a Java 7 vitafórumról. A régi általános paláver topik pedig itt van.

A fórumon leírtakon kívül még szóba került, hogy a Windows (Vista?) eléggé .NET alapú, ami érdekes helyzetbe hozhatja a JVM-eket. Márminthogy .NET-re kell írni a JRE-t. Jobban belegondolva nem hiszem hogy ez akkora gond lesz.

Érdekes dolgok történnek mostanában, annak ellenére hogy a Java halott.

Ha jövőre véletlenül a Javapolis felé vetődnék: Sajnos elfelejtettem, hogy Antwerpenben drága vagy olcsó a tömegközlekedés és a belvárosban vagy a külvárosban érdemesebb szállást foglalni. Arra emlékszem, hogy nem szép hely, viszont jövőre is ugyanott lesz a JP.

A következő JUM március 19.-én lesz és elvileg GWT-re, SOA-ra már lehet számítani. Sörözés közben még súgtak izgalmas ötleteket a következő vagy az azutáni JUM-ra, de nem tudom mennyire publikus úgyhogy nem írom le.

2008-01-13

Swing GUI trükkök

Éppen Swing-gel tolom. Íme néhány szépség, csak hogy látható legyen, hogy nemcsak a webes GUI készítésnek vannak meg a szépségei.

-A JFileChooser nagyon lassú Java 1.6_02-vel és 1.6_03-mal Windows-on, ha a megnyitott könyvtárban nagy zip fájlok vannak. Van róla bug report is. Több percig is eltarthat, mire megjelenik a dialógus ablak. Addig a hívás blokkolva van. 1.6_01-gyel nem lassú és ahogy nézem az 1.6_04 release notes-jában szerepel hogy javították.

-Swing komponens konstruktorába továbbra sem érdemes bepakolni a setVisible(true) hívást. Főleg modális dialógus konstruktorába, mert akkor a konstruktor hívása után már nem lehet semmit hozzádrótozni, mivel a setVisible(true); utáni kódrész csak a dialógus lezárása után hívódik meg. Modális dialógust átírni nem modálisra (és visszafelé) eléggé termékeny a hibalehetőségek szempontjából. Különben sem jó ötlet túl sok mindent bepakolni a konstruktorba, ez általános szabály két dolog miatt: 1. Biztos nem lenne hasznos valahol máshol a konstruktorba került inline funkcionalitás egy külön függvényként? 2. Öröklésnél a szuperosztály konstruktorának hívásánál még nincsenek beállítva a leszármazott osztályok mezői. Emiatt konstruktorban nem szerencsés a leszármazott osztályban (felül)definiált metódust hívni, főleg ha az a leszármazott osztály mezőit is használja.

-A JScrollPane-be ágyazott JPanel-eknek van egy rettentően kényelmetlen tulajdonságuk, mégpedig hogy amikor az egérrel görgetjük a külső scrollpane-t és ráfut az egér egy belső panelre, a görgetés hirtelen abbamarad. Erre lehet leleményes workaround-okat csinálni, kérdés hogy melyik Look and Feel-en hogyan működik.

-Look and Feel-eket cserélgetni programfutás közben -bár csábító a lehetőség- nem igazán ajánlatos. Nem mindig sikerül minden úgy ahogy kéne. Nálam néha beragadtak komponensek, azaz a GUI nagy része lecserélődött, de egy-két gomb megmaradt a jól megszokott metál stílusban. Különben -ahogy a JavaPosse-ben megmondták, a Swing Look and Feel-ek kicserélhetősége csak egy elméleti dolog, mert nem skin-ekről, hanem komponensekről van szó. Ha egyik készletben egy komponens így működik másikban meg úgy, az zavart okozhat. Említettek valami okosságot a témában, majd utánanézek. Egyelőre nem találtam meg, csak egy oldalt, ahonnan sokféle L&F letölthető. (JavaPosse 103)

-A JLabel és JButton kényelmetlen tulajdonsága, hogy többsoros szöveget csak HTML tag-ek segítségével tud megjeleníteni. Ez nem is lenne baj, viszont ilyen többsoros szövegnél már nem működik a setEnabled(false). Ajánlanak különféle megoldásokat, de egyik sem nagyon elegáns. Az alapprobléma az, hogy nem mindig elég egyszerűen kiszürkíteni a feliratot, mert némelyik look and feel-ben a bevésett halvány szöveg jelenti a letiltott label-t. Próbáltam azt is, hogy egy JEditorPane-t konfiguráltam úgy, hogy labelnek nézzen ki, de az meg a fókuszt kavarta el az oldalon és ezt nem is tudtam kiküszöbölni a setFocusable-vel és társaival. Végül úgy csináltam meg, hogy HTML-es labelt használtam, aminek setEnabled(false)-nál mondtam egy szürke színt és kész.

-A Swing komponensekhez a setClientProperty()-vel objektumokat lehet rendelni, amit aztán a getClientProperty()-vel vissza lehet olvasni.

-A Swing eseménykezelését továbbra is érdemes tanulmányozni. Legrosszabb megoldás ha egyáltalán nem foglalkozunk vele (eseménykezelőben, pl. actionPerformed semmi új szál, hanem csak az akciókód - ilyenkor hosszabb műveleteknél a GUI úgy néz ki mintha lefagyna), közepesen rossz megoldás ha mindig külön szálat indítunk az eseménykezelőkben. Jó megoldás az invokeAndWait és az invokeLater használata.

-A fest-tel nagyon jól lehet Swing-es GUI-kat tesztelni. Töltögeti a szövegmezőket, nyomogatja a gombokat szorgalmasan ahogy beprogramoztuk, csak legyen beállítva a Swing komponensek neve és legyen úgy görgetve a scrollbar, hogy látszódjon az ablakban amire klikkelni kell. Egyszerre egy klienst lehet tesztelni és jól lefogja az egész desktopot, úgyhogy ilyen jellegű tesztelésnél érdemes újságot, könyvet vagy másik számítógépet kéznél tartani, vagy elmenni kávézni.

-Ezt is beraktam a csőbe, majd valamikor elolvasom: WebCream 6.0 Swing alkalmazásokból AJAX-os webalkalmazásokat csináló medzsik (lásd még: Javaposse 137).

Amíg az embernek nincsenek túl nagy extra igényei egész jól el lehet lenni Swingben. Azonkívül ez még mindig igazán szórakoztató ahhoz képest, mint amikor JSF-ben (GWT-ben, Tapestry-ben vagy akármilyen webes GUI keretrendszerben) kell percenként aknákat kerülgetni.