Ma reggel olvastam a jdk7-dev listán (nem mintha rendszeresen követném, de ezen megakadt a szemem), hogy a Java 7-be végül mégis bekerülnek a lambda függvények/closure-ök, kinek hogy tetszik, az a lényeg hogy lesznek, aki nem tudja mi az az nézzen utána.

Szóval örülünk, igazából nagyon furcsa is volt, hogy ez eddig nem volt rajta a fícsörlistán, úgy tűnik az oracle rámordult a java lang expert group-ra hogy ugyan csak kéne már így 2010-ben. Ez persze részben meglepő, mert nemrég még úgy volt, hogy minél hamarabb (tavasszal) ki akarják adni a java 7-et. Üröm az örömben, hogy így kb. szeptemberre tolódik a release (ami azért elég gáz ha azt nézzük hogy eredetileg 2008 tavaszán kellett volna kijönnie), de azért én összességében örülök.

Hogy milyen lesz a lambda függvények szintaxisa és hogy az hogy fog bájtkódra fordulni, azt még senki nem tudja, elég sok ötlet kering ezzel kapcsolatban és a nagykutyák mind más megoldást pártolnak, na de ehhez is lesz majd JSR meg expert group meg community úgyhogy megoldják szeptemberig gondolom. Szerintem mondjuk elég egyértelmű hogy úgy kell lefordítani mint a névtelen osztályokat, amúgy is azokat használjuk most lambda függvények helyett (pl. swing eseménykezelésnél).

Aminek nem igazán örülök, az az, hogy kivették a Swing JDatePicker komponenst is :( szegény swingbe rájár a rúd így az utóbbi időben, először a Swing Application Frameworköt vették ki, most meg ez. Előbbit még meg is értem, biztos bonyolult téma (mondjuk kb mindent elmond a Swingről hogy a Sun-nál nem bírták alapjaiban sem eldönteni hogy hogy kellene swing programot írni...), utóbbit (JDatePicker) viszont nem igazán értem. Mi olyan veszettül nehéz egy ilyen komponens implementálásában??

Na mindegy, a swing eddig se volt a Java csúcsa, úgyhogy nem dől össze a világ, a closure-öknek meg örülünk nagyon.

További részletek itt, itt, itt és itt

Na most hogy az oracle-nek végre sikerült elég EU-s nagykutyát lefizetni ahhoz hogy megvehesse a Sun-t, úgy érzem itt az ideje hogy én is pampogjak valamit az üggyel kapcsolatban.

Kezdjük talán azzal a fölöttébb aktuális dologgal (az utóbbi napokban sokan blogoltak ezzel kapcsolatban), hogy mi lesz a Java-val. Sokan attól félnek hogy az oracle be fogja zárni a platform eddigi meglehetősen nyílt fejlesztését, de ez szerintem hülyeség. A Java technológiák attól életképesek és azért tudják felvenni a versenyt a .NET-tel, mert sok cég részt vállal benne: sun, redhat, ibm, google, oracle stb (most többet mondjuk nem tudok). A Sun ügyesen menedzselte a rendszert, alapvetően specifikációkat (JCP - Java Community Process) és referencia-implementációkat adott ki (pl. alkalmazásszerver, JPA stb), és a speckót bárki maga is implementálhatta. Ez belső versengést idézett elő a platformon belül, amiben a fent említett cégek részt vettek, és így van alternatíva minden lényeges dologra. Ez így faszán működik, ha jól tudom akkor 3x annyi a Java-s szoftverfejlesztés mint a .NET-es (fixme). Namost nyilván igaz hogy az oracle-re nem jellemző hogy ingyen adjon/nyílt kóddal adjon jó dolgokat, de ez nem jelenti azt hogy hülyék és rá fogják kényszeríteni teljesen a saját üzleti modelljüket a Sun-ra. Lehet hogy a specifikációk kialakításába kevesebb beleszólást engednek majd külsősöknek, de ezt eddig is 80%-ban a Sun végezte, meg vétójoguk is volt, magyarul nem dől össze a világ ha ezt mostmár teljesen az oracle csinálja. Annyira meg aztán tényleg nem hülyék, hogy az egész java platformot bezárják és maguk akarják fejleszteni, akkor az lenne a helyzet hogy Oracle (Java) vs. Microsoft (.NET), ezt pedig nyiván nem érdemes bevállalni. Magyarul röviden a Java miatt senkinek nem kell sipítozni szvsz.

Na nézzünk még meg néhány Sun terméket: a SPARC architektúrát nyilván fejleszteni fogják, baromira megéri hosszabb távon hogy saját hardvert fejleszthetnek a DMBS-ük alá, még akkor is ha perpill nem túl izmos a SPARC platform.

A NetBeans már kicsit húzósabb, van ugyanis az Oracle-nek egy JDeveloper nevű Java IDE-je, ami mondjuk nem túl elterjedt, a NB viszont gyorsan fejlődik, sokan használják és van körülötte közösség, meg üzleti modellt se nehéz tenni alá (már ha perpill nincs), úgyhogy én nem féltem. Az OpenOffice viszont elég gáz, nem hiszem hogy az Oracle-nek megéri irodai szoftvercsomagot fejleszteni - főleg nem ingyeneset - úgyhogy nem lennék meglepve ha elsorvadna az OOo (a community tuti nem fogja életben tartani eddig is 80%-ban a Sun fejlesztette). A MySQL meg gyakorlatilag szintén felejtős, ha úgy nézzük kb semmire nem kötelezte magát végül az ora a fejlesztésével kapcsolatban, viszont van helyette PostgreSQL úgyhogy pótolható, nekem a magam részéről nem fog különösebben fájni a szívem ha bedől a MySQL.

Nem nagyon szoktam személyes témájú posztokat írni, de most az lesz, nagyon pipa vagyok, érdemes elolvasni a sztorit.

Szóval ma volt az ACM programozó világverseny 1. fordulója. Kivételesen sikerült összeszedni egy Java-s csapatot (ugyebár ezen a versenyen 3 fős csapatok indulnak), úgyhogy már kezdtem örülni, hogy most végre talán jól fog sikerülni - korábban mindig céztünk, de mivel én itthon gyakorlatilag sosem kódolok cében, így általában belezavarodtam a pointerekbe.

A verseny reggel 10kor kezdődött, a jókedvem akkor kezdett megcsappanni, mikor 10:02-kor felébredtem. Na de üsse kavics, gyorsan összekaptam magam és befutottam kb fél11-re a suliba - ezzel nem is volt semmi bajom, én saram. A következő meglepetés az volt, hogy a csapattársaim sehol nem voltak, mindkettőnek sikerült elfelejtenie hogy ma verseny van. Na mondom nem baj Crystal, nyugi, így legalább nem fogunk pusztakezes földharcot vívni a gép előtti helyért (a három ember ugyebár egy gépet kap ACM-en).

Na itt még nem voltam kiakadva, 1,5 óra alatt sikerült (elvileg) megcsinálnom 1 feldatot, ami hozzám képest jó teljesítmény. Feltöltöm a forráskódot az ACM spanyolországi szerverére, és - itt jött a fekete leves, nem fordult a kód. Nézek ki a fejemből hogy wtf. Szólok a tanárnak hogy mi van, ő is néz ki a fejéből hogy wtf. Na ezzel így elvoltunk 1,5 órán keresztül mindketten, közben bősz fórum-turkálás, tesztelgetés, ilyesmi. Végül rájöttünk, hogy az ACM szerverén 1.4-es (ÖT éves) Java-verzió van, ami nem tudja hogy mi az hogy enum meg generikus. Hát majd' lefordultam a székről, miután összeszedtem magam fogtam magam és hazajöttem, amúgy is még bő 1 óra volt hátra a versenyből, azalatt max még 1 feladatot tudtam volna megcsinálni (és akkor mi van), meg hát én amúgy is elvből nem fogok Java 1.4-re fejleszteni.

Úgyhogy ennyit a világ legszínvonalasabb prog. versenyéről. Jövőre tuti nem megyek.

Nagyon nem tudja eldönteni a Java világ, hogy a Java után mi legyen a "nagy" JVM nyelv, a legújabb jelölt a Google által fejlesztett noop. Elég kezdeti stádiumban van a fejlesztése (fordító meg ilyesmi ha jól láttam egyáltalán nincs egyelőre), de mivel mégis csak a gugli dolgozik rajta, ezért kapott némi visszhangot - mindenképp nagyobbat, mint a többi (állítólag kb 200) JVM-en elérhető nyelv 98%-a.

Nem igazán látszik még, hogy mire lesz jó ez a nyelv, és nekem igazából egyáltalán nem tiszta az sem, hogy mi a célja a fejlesztésének, érdekesen keveri a szkriptnyelvek és "heavyweight" nyelvek jellemzőit. Nagyon sok fícsört beleraktak, ezek egyrésze nagyjából kötelező jellegű az új VM nyelvek számára, ilyen pl. az hogy nem használ primitív típusokat, háttérbe szorítja a kötelezően kezelendő kivételeket, ill. kedvencem, hogy jó lesz a standard könyvtára (bullshit :P). Itt is előkerül, hogy nem lehet static eszközöket használni, ezt több más helyen is láttam mostanában (scala, javafx), szóljon aki tudja hogy ez miért jó. Előkerül az is, hogy nyelvi szinten több dologhoz van literál (pl. hash, regex), ami általában inkább a szkriptnyelvek jellemzője, pedig láthatóan a noopot inkább nagyon nagy projektekre tervezik. Ezt sok sajátos nyelvi jellemző igazolja, pl. nyelvi szintű unit testing támogatás, a null érték elkerülése, ill. amit nagyon nem tudok mire vélni, az az, hogy beépített dependency injection támogatást akarnak rakni a nyelvbe, ami talán kicsit túlzás, főleg, hogy ez azt jelenti, hogy minden noop program alatt ott figyel a guice vagy PicoContainer DI framework.

Szerintem fölösleges ötlet, hogy a dokumentációs technológiát szintén lerendezi maga a nyelv, java-ból sem hiányzik senkinek, nem baj, hogy nincs szorosan összeheggesztve a java és a javadoc. Azt is több szempontból melléfogásnak tartom, hogy egy metódus több értéket is visszaadhat (fölösleges és zavaró, egy nagy projektben semmi nem múlik a plusz DTO-kon). Az egyébként nekem nagyon furcsa, hogy nem találtam a noopban funkcionális nyelvi elemeket, pedig mostanában a csapból is a funkcionális paradigma folyik.

Szóval összességében a noop egy nagyon inovatív nyelvnek tűnik, de nekem egyelőre inkább nem tetszik, mint igen - lehet, hogy ezt egy év múlva másképp fogom látni. Nem tudom, hogy a google mennyire gondolja komolyan ezt a projektet, de végülis a masszív marketing és hype elég lehet ahhoz, hogy elterjesszen egy amúgy közepes nyelvet, szóval tényleg franc tudja hogy mi lesz a következő 5 évben a JVM-platformon.

A Project Darkstar egy - a Java-világon belül - elég marginális területre fókuszál: a játékfejlesztésre. A projekt célja egy olyan szerver-motor létrehozása, melyre egyszerűen lehet fejleszteni real-time online játékokat, nyilván a legfontosabb kérdés a skálázhatóság, hibatűrés, stb, magyarul sokminden, amiben a java technológiák már bizonyítottak. Az érdekesség a dologban az, hogy a darkstar nem a Java EE technológiára épül, a futtatásához elég egy sima JRE.

Állítólag marha egyszerű fejleszteni a platformra, és - bár nem rágtam bele magam olyan nagyon a témába - úgy tűnik jól le is van dokumentálva a cucc, a kliens- és szerver-oldali része egyaránt. A kliens-oldali grafikai megoldás nyilván egy ilyen projektnél a Java3D technológia, ami egyébként mióta ki tudja használni a videókártyát, nagyon szép dolgokat tud.

Mindezzel együtt nem úgy tűnik, hogy a közeljövőben fel fog virágozni a Java-alapú játékfejlesztés. Nem mintha a technológia nem állna rá készen, inkább az a baj, hogy egyrészt gyakorlatilag nincs marketing a dolog körül (legalábbis én nem látom, hogy lenne), másrészt a PC játékfejlesztés - amennyire belelátok - nagyon nehezen mozdul a c++ directx/opengl vonalról. A legtöbb játékfejlesztő cég 2-5 évig dolgozik egy projekten, így gyakorlatilag nincs rá kapacitás, túl kockázatos, hogy új technológiákat kipróbáljanak. Az MS-nek sem nagyon sikerül a C#-ot (XNA Game Studio) elterjeszteni.

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.

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. :)

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.