Noop
bullet Crystal -- 2009-09-20
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.
JavaCC
bullet Crystal -- 2009-08-25
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.
JavaFX Script
bullet Crystal -- 2009-07-08
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. :)
ClassFileAnalyzer
bullet Crystal -- 2009-07-04
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.
C kreténség - kifejezés a bal oldalon
bullet Crystal -- 2009-08-28
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... :)
php - statikus metódusok 2
bullet Crystal -- 2009-06-15
Nem rég már írtam a php statikus metóduskezeléséről. A php 5.3-ban (aminek egyyébként most jelent meg a 3. RC kiadása) a dolog tovább bonyolódik, ugyanis bejön a static kulcsszó, ami a self-et egészíti ki/helyettesíti, késői kötést biztosít a statikus metódusoknak. Ha jól látom ez ugyanúgy fog működni, mintha az osztály nevével hivatkoznánk a metódusra (Myclass::mymethod()).

Azt hiszem az a legjobb megoldás, ha nem használunk statikus metódusokat php-ben. Csak engem emlékeztet lassan a c++-ra a bonyolultsága?
A statikus metódusok és a $this
bullet Crystal -- 2009-05-27
PHP-ben van ugyan static kulcsszó, de ettől függetlenül a nem statikus metódusokat is meghívhatjuk statikusan. A legtöbben úgy tudják, hogy egy metódus belsejében annak alapján lehet eldönteni hogy statikus metódushívás történt-e vagy nem, hogy létezik-e a $this változó. Ez azonban sajnos nem mindig igaz.

Kicsit alaposabban körüljártam a dolgot, és írtam egy demót, letölthető innen. A demóban két osztály van, a B osztályban vizsgáljuk a $this-t, az A osztályból pedig B metódusát hívjuk. Nézzük, mit csinál az index.php:

A 7-8 sorban az index.php-ből hívjuk egy B típusú objektum metódusát, az eredmény nem meglepő, a $this B típusú objektum. Ezután a 11. sorban statikusan hívjuk B metódusát, itt a $this értéke NULL, ebben sincs semmi meglepő. A 14. sorban létrehozunk egy A típusú objektumot, a továbbiakban ezzel dolgozunk. Először A egy metódusából hívjuk B metódusát, itt a $this szintén B típusú, ez is magától értetődő.

Az érdekesség most jön. Az A objektum nem-statikusan hívott metódusából hívjuk B metódusát statikusan. Ekkor a B metódusában a $this egy A típusú objektum lesz - a hívó objektum, tehát a metódushívás környezete (!!).

Nem tudom hogy ez bug vagy feature, ha bug akkor ismert-e vagy nem, még nem jártam utána, de lehet hogy fogok. Elég durva, nehezen felderíthető hibák következhetnek ebből a viselkedésből.

Valószínűleg az történik, hogy a futtatókörnyezet metódushívásnál először a $this-t rakja rá a veremre, ha nem statikus a hívás. A metódus pedig innen veszi le a $this-t - vagy amit ott éppen talál - mikor szüksége van rá. Statikus híváskor persze nem kapják meg ezt a paramétert, és mikor szükség lenne rá, akkor leveszik a veremről amit ott éppen találnak. Ez most az A típusú hívó objektum. Ennek némileg ellentmond, hogy ha átadok A metódusának egy paramétert, akkor is az $a objektum lesz a B-ben a $this, pedig ez alapján a paraméternek kellene lenni. Nem tudom, hogy pontosan mi történik, 3 ötletem van:

* az interpreter leveszi az összes paramétert a veremről a metódushívás végén és átteszi máshova (miért tenné?)
* a $this változó nem első, hanem utolsó paraméterként adódik át, így a következő metódus a hívási listán azt találja a verem tetején. Ez se valószínű, az OO kódok nem így szoktak futni.
* a hívási listához tartozó $this objektumok külön veremben vannak, nem együtt a többi paraméterrel. Ez tűnik számomra a legvalószínűbbnek, bár ez is elég furcsa.

Majd ha jutottam valamire a dologgal akkor írok :)

Végül a teszt végén még A metódusát hívjuk statikusan, abból pedig B metódusát szintén statikusan, ilyenkor - nem meglepő - a $this értéke null lesz.
Jasmin
bullet Crystal -- 2009-04-12
A Jasmin a Java Assembly Interface rövidítése, tehát "bytecode assembly"-ből fordít java bájtkódot. A bájtkódnak egyébként nincs szabványos assembly-szintű reprezentációja, a jasmin által értelmezett szintaxis számít de-facto szabványnak.

Persze kérdés, hogy mi értelme van egy assembly nyelven jvm-re programozni, mert hát tulajdonképpen semmi, max akkor jön jól, ha egy zárd kódú java programot akarunk hackelni. Ettől függetlenül java programozóként érdemes egyszer kipróbálni.
JSMag
bullet Crystal -- 2009-03-09
Elindult a JSMag, egy javascripttel foglalkozó online magazin. Sajnos az újság $4.99-be kerül, ami azért magyar viszonylatokban elég sok. Pedig az első szám tartalma alapján nagyon színvonalas lehet, komolyan elgondolkodtam rajta hogy megrendelem.
Az 1. szám tartalma:

* ExtJS: bevezetés
* A piros pirula: funkcionális programozás JS-ben
* Unit-tesztelés JS-ben
* JS kód debugolása
* jQuery 1.3 újdonságok
Kitúrják a Java-t a JVM-ből?
bullet Crystal -- 2009-03-07
Rövid bevezető a problémába: a Java nyelven írt programok forráskódját általában úgynevezett java bájtkódra fordítja a fordító (van olyan gnu-s fordító ami képes natív gépi kódra fordítani a forráskódot, de ezt elenyészően kis méretékben használják). A forráskód-fájl kiterjesztése .java, a bájtkód-fájl kiterjesztése .class. A program (a class fájl) aztán úgy fut le, hogy egy virtuális gép (egy natív program) - jvm, java virtual machine - megkapja paraméterként, értelmezi és így lefuttatja. A bájtkód (a program) így hordozható, mivel bármilyen architektúrára meg lehet írni olyan programot (vm-et), mely képes értelmezni, futtatni a bájtkódot.

Az az érdekes a dologban, hogy nem csak a java forráskódot lehet lefordítani java bájtkódra, hanem más nyelveken írt programokat is, pl. python (jython), ruby (jruby), erlang kódot, vagy vannak olyan nyelvek is, melyeket kifejezetten jvm-re terveztek, pl groovy, ill. (ha jól tudom) a scala is ilyen. Ennek köszönhetően ha java programra van szükségünk, akkor ezt nem csak java nyelven írhatjuk meg, sőt akár azt is megtehetjük, hogy egy program ülönböző részeit különböző nyelveken írjuk meg. A JVM így ma már egy soknyelves platform, valójában sokkal több JVM nyelv van (és ezek közül a java csak az egyik) mint .NET nyelv, pedig eredetileg a java platform egynyelves környezet volt, és a .net platform nagy előnyének számított hogy több nyelven (c#, vb, asp) lehetett fejleszteni rá.

Mostanában egyre több amerikai blogger ír arról hogy a java kezd elavulni, túl robosztus és nehézkes a nyelv, és a Java platformot a java helyett más JVM nyelvek fogják uralni (pl. scala, erlang, groovy). Érdekes lehetőség, bár én a magam részéről nem szeretném az egész java tudásomat kidobni az ablakon, meg persze elég valószínűtlennek tűnik hogy a javát kipaterolják a saját házából :) - bár még nem néztem bele más vm nyelvekbe. Persze fontos látni, hogy a Java OO nyelv, a scala meg erlang pedig funkció-orientált nyelvek, tehát magasabb programozási paradigmába tartoznak, és ugyan a funkció-orientáltságot manapság hypeolják rendesen, azért nem eszik olyan forrón a kását, sok idő kell még ahhoz, hogy (főleg Európában) felváltsa az OO-t.