A Sun (vagy lehet inkább most már az Oracle-ről kellene beszélni) nem éppen a desktop platformjáról híres, de azért megtesz ezt-azt a fejlesztéséért. A Java Store egy olyan online szolgáltatás, melyen keresztül a felhasználók saját fejlesztésű desktop alkalmazásaikat tölthetik fel, és így azokat ingyen vagy pénzért terjeszthetik. Ezek az programok nyilván elsősorban swinges és JavaFX cuccok lesznek, legalábbis ez lenne a cél.

A Java desktop a JavaFX kapcsán már megmutatta, hogy minél jobban alkalmazni akarja a write once - run anywhere elvet, mivel elméletben a JavaFX programok egyaránt futtathatóak telefonon, böngészőben és desktopon. Ezt a hozzáállást a Java Store is követi, ezért különválasztották tőle a back-end szolgáltatását, a Java Warehouse-t. A programozó a warehouse-ba tölti fel az elkészült alkalmazást, a warehouse-hoz pedig különböző kliens-szolgáltatások kapcsolódnak, melyek felületet adnak a végfelhasználónak a letöltéshez - jelenleg az egyetlen ilyen kliens a Java Store. Nyilván az a cél, hogy legyen egy olyan kliens is, ami mondjuk telefonon fut. Más platform most így hirtelen nem is jut eszembe...

A Java Warehouse/Store szolgáltatások jelenleg private beta állapotban futnak, ez azt jelenti, hogy csak USA-beli fejlesztők használhatják, és nekik is meghívót kell hozzá igényelni. Valamikor 2010-ben kerül majd public állapotba a szolgáltatás.

Mikor először néztem utána ennek a Java Store témakörnek, a FAQ-ban egy elég érdekes bekezdést találtam, nagyjából az volt a lényege, hogy a private beta program után az egész szolgáltatás fizetős lesz - magyarul fizetnem kell majd azért, hogy - akár ingyenes - programokat feltöltsek a warehouse-ba. Ez eléggé olyan fafej oracle-s hülyeségnek tűnik, eléggé ki is buktam mikor ezt olvastam - azt még megértem hogy az Oracle nagyobb profitot akar kihozni a Sun-ból, de ne ilyen kretén módon már... Most nem találom ezt a részt, remélem azóta eltűntették, ez is olyan "baki" volt, mint az, mikor a G1 garbage collector használatát fizetőssé akarták tenni.

A JavaCC a Java Compiler Compiler rövidítése. Egy olyan eszközről van szó, amely adott formális nyelvhez generál Java nyelvű (azaz java forráskód keletkezik) lexikális elemzőt és tokenizert, tehát hasonló eszköz, mint a yacc, csak ez java-hoz van. Meg kell adni neki egy input fájlt, melyben leírjuk az adott formális nyelvet, és megtűzdeljük java kódrészletekkel, ide írjuk azt, hogy a parszolás közben mit akarunk csinálni. A javacc program pedig ebből előállítja a tokenizert. Meglepően könnyű használni a programot, tehát ha olyan programot írunk, melyben a bemenet a triviálisnál valamivel bonyolultabb - esetleg saját programnyelvhez készítünk fordítót -, mindenképp érdemes a JavaCC-vel készíteni a parsert, sok szívástól megkímélhetjük magunkat.

Tegnap végre rászántam magam, és váltottam fluxbox ablakkezelőre. Ez egy nagyon erőforrás-takarékos ablakkezelő, a memóriaigénye töredéke a nagy ablakkezelőkének (GNOME, KDE), sőt még több más - magát lightweightnek beállító - ablakkezelőnél (pl. XFCE, LXDE) is jóval kisebb. 2009-ben így 1gb memóriával már lassan el kell kezdenem ilyesmivel foglalkozni, egyre többször swapol a gép (főleg fejlesztés közben).

A fluxbox minimális memória-igényének persze megvan az ára. A máshol megszokott ablakozós beállítás helyett itt konfig fájlokat kell szerkesztenünk, ami elég sok guglizással jár és sokáig tart, rá kell szánni legalább fél napot, hogy az ember ideálisan beállítsa a rendszert. Az alapbeállítások elég esetlenek, egyrészt nagyon csúnya a téma, másrészt (nekem legalábbis) nagyon nem állnak kézre a dolgok, de ettől nem kell megijedni, egész kényelmesre ki lehet pofozni néhány óra alatt. Egyébként a keybinding elég sokat tud, tehát nagyon sokmindenhez beállíthatunk hotkeyt, az ablakokat szétoszthatjuk 5 különböző rétegbe, így könnyen megoldható, hogy az egyik ablak mindig látszódjon a másik fölött (és emellett áttetszővé is tehetőek az ablakok), stb, szóval van pár olyan feature amit máshol eddig nem láttam. Szóval összességében az első benyomás után kicsit nehezen vettem rá magam, hogy átálljak, de úgy tűnik megérte.

Az utóbbi napokban ismét kicsit aktuálisabbá vált a progtut.net 2.0 probléma, a portálon mostanában kicsit felpezsdült az élet (by elodani:)), így most már tényleg ideje lenne megírni egy korszerűbb és használhatóbb portált.

Az új portált Java-ban szeretném írni, php + kohana párossal valószínűleg kisebb meló lenne (mivel abban már több tapasztalatom van), de a java nyelvet sokkal jobban szeretem, és hiszek benne, hogy gyorsabb mint a php. Viszont nekem eddig úgy tűnik, hogy a php frameworkök kiforrottabbak és alkalmasabbak portálfejlesztésre mint a java frameworkök, jobban és egyszerűbben megoldják a tipikus webfejlesztéssel kapcsolatos problémákat. Ahhoz képest hogy milyen fapados technológia a php nagyon jók a keretrendszerek (amikkel találkoztam: CodeIgniter, Kohana, Zend, Yii). Az általam ismert java frameworkök közül valamelyik általam fontosnak tartott feature mindegyikből hiányzik.

Na de nem adom fel, keresem a megfelelő java keretrendszert. Lássuk mit szeretnék:

* layout page / content page rendszer egyszerűen megvalósítható legyen és emiatt ne kelljen lemondani az egyéb feature-ökről

* a fenti viselkedés egyszerűen letiltható legyen egyes action-ökben, hogy lehessen ajaxozni és rss feed-eet generálni

* szépek legyenek az URL-ek, kohana/CI-szerűen az URL egyes részeit át lehessen adni paraméterként a controllernek

* a request paramétereket automatikusan rakja be a framework egy bean-be, és legyen kiforrott annotáció / xml alapú validációs mechanizmus

* lehessen vele Java objektumot JSON-ba konvertálni

* ne akarjon beleszólni a framework a layout-ba, ne határozza meg az oldal struktúráját

* esetleg még az jó lenne, ha a frameworköt lehetne GWT-vel integrálni

Úgy nagyjából ennyi. Szerintem nem kérek sokat...
Eddig a struts-ot és a stripes-t néztem, mindkettő több pontnál elvérzett, de szerencsére van még miből válogatni :)

Persze ez nem azt jelenti, hogy a java nem alkalmas webfejlesztésre. Inkább arról van szó, hogy a java frameworköket inkább nagy alkalmazásokhoz, belső céges ügyviteli portálokhoz, rengeteg űrlap gyors (automatizált) kezeléséhez fejlesztették, így nem a progtut.net-szerű portálok jelentik a tipikus feladatokat. Nyilván kiváló technológiák a GWT meg a JSF, de arra alkalmatlanok, hogy az egész progtut.net-et ezekre alapozva írjam meg.

Ha valaki tud a fenti kritériumoknak megfelelő Java keretrendszert, az ne tartsa magában :)

Pár napja foglalkozok már a JavaFX technológiával, itt az ideje, hogy összefoglaljam az első tapasztalatokat :) Ebben a postban kizárólag a JavaFX saját nyelvéről, a JavaFX Script-ről fogok írni (tehát ebbe nem tartozik bele az API és az IDE támogatottság).

A JavaFX a szkriptnyelvek tipikus jellemzőit hordja magában, sok elemet felfedezhetünk benne a php, python, javascript nyelvekből. JVM nyelv, tehát nem java, de java bájtkódra fordul (régebbi írásom a témáról), és ez azért itt-ott érződik is rajta, a típustalansága csak látszólagos (ezzel néha akadnak is problémák, vannak dolgok, amiket a fordító nem tud kezelni).

A nyelv nem túl bonyolult, a referenciát 2-3 nap alatt át lehet nézni (bár ez a dokumentum még erősen hiányos). A legjobb és legfontosabb feature azt hiszem a binding, amivel sok favágó kódot megspórolhatunk, ha MVC modellt használunk (és ugyebár azt használunk:)), akkor a binding segítségével könnyen rá tudjuk drótozni a UI-t a modellre, ami nekem nagyon tetszik.

Érdekes dolgokat találunk a nyelv tömbkezelése környékén. Egyrészt tömbök tulajdonképpen nincsenek is, a referencia szekvenciának hívja őket, de mivel ennek nem fix a mérete, ezért szerintem nem felel meg az általános tömb-fogalomnak (egyébként ennyi erővel a php tömb sem igazi tömb). Szóval a szekvenciában az a nagyon furcsa, hogy csak egydimenziós lehet, amit nem igazán értek, nem lenne nehéz megoldani, hogy többdimenziós is lehessen. Persze mindent meg lehet oldani egy dimenzióval is, csak hát szívás. Ezt a "fícsört" egyébként a nyelv tömbkezelő műveletek gazdag arzenáljával kárpótolja, amiben egyébként tényleg vannak jó dolgok.

Closure-ök ("inline függvények" ha úgy tetszik) szkriptnyelvhez méltóan szintén vannak, ami mindig egy izgalmas lehetőség pl. eseménykezelésünk megvalósítására. Érdekes, hogy a java-val szemben a JavaFX Script támogatja a többszörös öröklődést, ami lövésem sincs hogy milyen bájtkódra fordul, majd ha kicsit több időm lesz utánanézek.

Na most elsőre ennyi, folyt. köv. :)

A JavaFX technológiában az (lenne) az egyik nagy feature, hogy ugyanaz a program egyaránt fut telefonon, böngészőben és desktopon. Nos, az első programomat desktopra írtam, hát nem volt egyszerű NetBeans-en kívül lefuttatni. Böngészőben egyébként ugyanaz a program simán ment, és a netbeans által generált .jnlp fájlt (Java WebStart formátum) a javaws program is tudta futtatni konzolból indítva, csak ez így kicsit ronda volt, az ablak tetejére ki volt írva ronda szürke alapon hogy "Java Application Window" (kb úgy mint mikor egy applet megjelenít egy message boxot - már ha ez mond valakinek valamit), ami némi helyet is foglalt így kilógott pár widget alul az ablakból, úgyhogy más megoldást néztem. A desktop futtatás a dokumentációban standard-run néven szerepel, namost ezt elvileg úgy kellene, hogy az ember elindítja a javafx programot, és átadja neki paraméterként a futtatandó osztály nevét. Ami rendben is lenne, csak a javafx program nincs benne a jre-ben (a legújabban sem), csak a javafx sdk-ban - az pedig nyilván nem megoldás, hogy az ember a program mellé adja a fejlesztői környezet egy részét is (még akkor sem, ha egy rövid shell scriptről van szó). Néhány óra szenvedés után a javafx sdk-ban található javafxpackager programmal sikerült lefordítani úgy a cuccot, hogy simán a java programmal lehessen futtatni, és classpath gond miatt se álljon le, röviden annyi volt a lényeg, hogy a javafxpackager a jar fájlba berakott egy cmo.sun.javafx.runtime.main.Main nevű class fájlt, és ezt kell futtatni mint főprogramot - ebben van a main metódus, ez lesz a futtatókörnyezet a javafx programunk számára, és át kell adni neki a ténylegesen futtatandó class fájlt. Ugyanezt belesuvasztani a netbeans által használt ant build fájlba már nem volt erőm.

Ami viszont jó hír, az az, hogy jre 1.6 update 4 is tudta futtatni, tehát nem kellett hozzá a legújabb update 14.

Pár hónapja írtam a Jasmin-ról, ami egy java bájtkód assembler, azaz egy assembly-szintű nyelvből fordít java bájtkódot.

Nyilván ennek önmagában nincs sok értelme, gyakorlatilag senki nem olyan mazoista hogy nekiálljon kézzel (majdnem)bájtkódot írni. Elég sokáig tartott, mire találtam olyan java disassemblert, ami jasmin-komaptibilis assembly-re fordítja vissza a bájtkódot, de végül meglett, ő a ClassFileAnalyzer (nagyon fantáziadús neve van :)). Nekem jól fog jönni, érdekel a jvm és a bájtkód működése, de azért az kicsit sok lenne, hogy hexa editorral olvassak class fájlokat... Most elkezdtem JavaFX-et tanulni - majd írok arról is -, és sok nyelvi szerkezet érdekelne, hogy milyen bájtkódra fordul, ezért kerestem disassemblert.

Megjelent a JavaFX 1.2, és mostmár van Linux és Solaris támogatás is. Már kezdtem aggódni, hogy sosem fog megjelenni a linux SDK, ez a bő fél éves csúszás a Windows/OSX verzióhoz képest kicsit sok volt, de legalább megérkezett.

Én ha lesz időm biztosan kipróbálom, amúgy sem foglalkoztam még komolyabban semmilyen RIA platformmal, és a JavaFX ígéretesnek tűnik, vagy legalábbis - amennyire én látom - elég nagy felhajtás van körülötte. Van hozzá NetBeans támogatás is, aminek szintén örülünk.

Letöltés innen

Tutorial itt

A probléma tárgya a következő értékadás:

(a ? b : c) = 5;

Tehát az értékadás bal oldalán egy feltételes kifejezés szerepel. Első ránézésre elég furcsa, de végülis van értelme, és mivel a kifejezés eredménye mindenképp egy változó lesz, ezért akár le is lehetne fordítani. Sőt, ennek alapján a gcc-nek le is kellene fordítania, de nem teszi.

Egyébként a szerkezet gyakran hasznos tud lenni, sokszor jó lett volna már, pl. gondoljunk egy bináris keresésre. Adott esetben még némi memóriát/sebességet is meg lehet spórolni vele. Ha mégis ilyet szeretnénk csinálni, akkor írhatjuk így:

*(a ? &b : &c) = 5;

Kicsit nyakatekert, de működik. Olvashatóság szempontjából persze nem a legjobb... :)

A Prism egy firefox-addon, melynek segítségével úgy futtathatunk alkalmazásokat, mintha desktop programok lennének. Gyakorlatilag egy minimál-böngésző (tényleg minimál, ugyanis semmi nincs az ablakban), amihez be lehet konfigurálni különböző webalkalmazásokat. Az benne a szép, hogy nem úgy működik, hogy elindítjuk a prism-et és utána csatlakozunk az alkalmazáshoz amit éppen használni akarunk, hanem mikor felveszünk egy alkalmazást prism-ben, akkor beállíthatjuk, hogy hol legyenek hozzátartozó shortcut-ok (mondjuk én ubuntun csak az asztalra tudtam tenni, winen nem tudom), és így "közvetlenül" indíthatjuk a programot - valóban olyan, mintha desktop alkalmazás lenne. Nem egy tabban fut a böngészőben, és nincsenek benne az olyan sallangok - könyvjelzők, menü, stb - amire az alkalmazásnak úgysincs szüksége és csak foglalja a helyet. Valljuk be, a gmail webes kliensének vagy egy bugtrackernek pl. nincs sok keresnivalója a browserben.

Azt hiszem a következő években az lesz a tendencia, hogy összefolynak a desktop és webes programok, és ebbe az irányba nagyon komoly lépést jelent a prism. Tulajdonképp itt már tényleg mindegy, hogy mondjuk egy cloud szolgáltatással egy desktop vastagklienssel vagy egy html alapú vékonyklienssel kommunikálunk, a felhasználó számára nincs különbség. Megfelelően átgondolt tervezés esetén persze a programozónak se gond portolni a klienst, de ez már másik téma :)