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 igazán friss hús, de most kéne tanulni, úgyhogy most próbáltam ki a NetBeans legújabb verzióját. A php és javafx verzió érdekelt, a Java-ról egyrészt elhiszem hogy nagyon jó, másrészt kicsit mostanában (sajnos?) mellékvágányra került nálam a téma, a többihez (ruby, c/c++) pedig nem értek.

Először 1-2 hete a NetBeans for PHP-t néztem meg, hát mit ne mondjak rég láttam ilyen jó php környezetet. Na nem mintha sokat várnék, de ami kell azt tudja: syntax highlight megy, rendesen működik az auto-completion (legalábbis kohana-s cucchoz, aminek ugyebár kb ugyanúgy működik az autoloadere mint a ZF-é, ez mondjuk lehet benne van a dologban), ráadásul normális a sebessége is. Összehasonlításképp: eclipse-ben az autoloader hol megy, hol nem, és ha megy, akkor is döglassú.

Ezen kívül kipofozták a JavaScript syntax highlightert, 6.1-ben még elég pocsék volt, mostmár rendesen megy (legalábbis én nem tudtam olyan kódot produkálni a rászánt 2 perc alatt amitől megfeküdt volna). Ráadásul a standard DOM API-hoz van autocompletion és még popup doksi is, szóval igazán tisztességesen meg van írva a js támogatás is, nem nagyon láttam még ehhez hasonlót. Ha már így benne voltam megnéztem a CSS szerkesztőt is. Na itt lepődtem meg igazán, ugyanis nem csak hogy rendesen működik, hanem egy dobozban megjelenítni on-the-fly hogy az éppen szerkesztett CSS utasítás hogyan fog formázni egy divet, ráadásul ez is normális sebességgel működik - csöpögök.

Szóval PHP téren jelenleg nagyon odaveri a netbeans az eclipse pdt-t, érdemes váltani.

Ezután jött a JavaFX-es NetBeans, ettől már nem voltam annyira elragadtatva. Telepítés közben kicsit meglepődtem, mert a telepítő nem kérdezte, hogy hova akarom rakni a cuccot, hanem észrevette hogy már van egy NB telepítés a gépen (a php-s) és abba másolta a javafx-es cuccokat is. Gondolom ez nem javafx-specifikus dolog, hanem úgy alakították át a netbeans-t hogy egy gépen csak egy telepítés lehessen. Nem vagyok túl boldog tőle dehát istenem, ettől még nem dől össze a világ.

Viszont ez a JavaFX támogatás sehogy nem akar jó lenni. Még mindig nincs hozzá normális drag&drop editor, amit annak neveznek az annyi, hogy ráklikkolok egy gombra és a kódba beilleszt az adott widgethez egy sample kódot - akkor is, ha épp rossz helyen áll a kurzor és syntax erroros lesz a kód. Van még újításként egy preview nevű ablak amiben elvileg látjuk hogy hogy fog kinézni az éppen szerkesztett UI, ez elvileg nem lenne rossz csak ahogy néztem kicsit döcögve működik. Ezen kívül még mindig vannak olyan banális hibák, mint pl az hogy ha a forráskód hibás volt, aztán javítom, attól még a fájl ikonja továbbra is hibásnak jelzi, meg ilyesmi. Na nembaj legalább a kódszerkesztő jobban működik mint 6.5-ben.

Egyébként bekerült a netbeans-be egy olyan feature hogy az internal frame-eket lehet undockolni és akár másik workspace-re helyezni, ezt én pl az eclipse-ből nagyon hiányolom, úgyhogy most ennek szintén örülök:)

Kicsit kezdem megunni, hogy divatdisztrót (még mindig ubuntut) használok, meg nem is szeretem hogy elég sok dolog van benne - valszeg még mindig pedig már takarítgatom egy ideje - amire nekem semmi szükségem. Meg az is kétélű dolog hogy jól működik, persze nem rossz dolog ha nem kell állandóan reszelni, de reszelés nélkül meg sose lesz az emberből linux guru. Úgyhogy mindezen okokból kifolyólag még nyáron eldöntöttem hogy kipróbálok valami minimál disztrót, ez lett a zenwalk. Namost a gépemmel van egy olyan apró probléma, hogy nem működik benne a cd/dvd meghajtó, mitöbb ha másikat teszek bele az se működik (ez amúgy egy 2,5 évvel ezelőtt alaposan elbaszott solaris telepítés óta van így, szóljon akinek an bármi tippje h mi lehet a baj), úgyhogy nálam az oprendszer telepítés nem egyszerű történet (plusz az alaplap nem támogatja az USB-ről való telepítést). Szóval nyilvánvaló volt hogy valami olyasmit kell csinálni hogy dd-vel átmásolni /dev/sdaX-ra a telepítő iso-t aztán grubba beírni ezt a partíciót és aztán bebootolni a telepítőt. így esett a választásom a zenwalk-ra, mivel a zenwalk wikiben van leírás a vinyóról telepítésről. A zenwalk core elég minimálnak tűnt ahhoz hogy vidám szívásokkal kecsegtessen, így hát felraktam. Ez volt aug. végén.

Akkor aztán végül install után nem sokat foglalkoztam vele, némi szenvedés után kicsit elment tőle a kedvem, de aztán most itt van a vizsgaidőszak, hogy tegnap este végül már annyira nem tudtam magammal mit csinálni tanulás helyett, hogy ismét bebootoltam a zenwalkot.

Hát nem tudom hogy ez a disztró nagyon szar, vagy nagyon minimál, vagy csak az én puha ubuntus seggemnek kemény, valszeg leginkább nem mindhárom. Kb 3 órát szenvedtem vele - nem akarok sokat, egyelőre elég lenne ha lenne egy működő fluxboxom rajta. Namost az állítólag nagyon jó zenwalk csomagkezelőről annyit, hogy a xorg nem volt fluxbox függőség, mitöbb ahhoz is külön le kellett szedni egy külön csomagot, hogy a csomagkezelő rendesen tudja kezelni az általa leszedett .txz csomagokat.. Namost többször is újraraktam közben a rendszert, ennek során kiderült, hogy a "tükörszervereken" egyáltalán nem ugyanazok a csomagok vannak, erre nem igazán tudok mondani. Ott adtam fel, mikor az egyik tárolóból leszedtem az összes xorg-* csomagot, de nem volt startx parancsom meg xorg.conf-om.

Szóval ez a zenwalk core dolog így másodjára se jött össze, annyi előnye legalább volt hogy megtanultam lynx-szel guglizni -.- majd lehet hogy valamikor futok vele mégegy kört.

Elindult a KForm projekt, egy új formolós modul Kohana-hoz. Nem egy nagy dolog, view scriptek nélkül 150 sor az egész, de szerintem sokat tud, és egész jól használható. A wikiben van hozzá tutorial, szerintem nagyjából minden le van benne írva, kéretik próbálgatni, tesztelgetni, aztán bugreportokat kérek a projekt oldalán, vagy akár itt is. Kohana v3-hoz van írva, amihez amúgy megjelent egy egész használható wiki, úgyhogy mostmár kicsit könnyebben tanulható a cucc.

A view scriptek szintjén azért hoztam a formám, csapnivalóan rondák :) de ha minden igaz Vil már patkolja.

Ja, igen. Ez a 100. poszt a blogon :)

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.

16.-án némi csúszás után megjelent a Kohana framework 3.0 verziója - kódnevén "renaissance". Az új verzió tulajdonképpen egy teljesen új keretrendszert hozott (majdnem az egészet újraírták), ami ugyan sokmindenben hasonlít a 2.x-es szériára, de egyáltalán nem kompatibilis vele. Átalakították a konfigurációt, minimálisra csökkent a szekvenciális bootstrap kód (index.php meg még ami utána jön), ami van, annak is a nagy része olyan dolog, ami eddig a konfig könyvtárakban volt.

Sokkal egyszerűbbé vált az autoloader: korábban dedikált könyvtár volt a különböző feladatokra, controllers, models, libraries, stb. Most gyakorlatilag az egészet benyomták egy classes könyvtárban, amin belül az autoloader rendkívül egyszerűn működik - úgy, mint a zend frameworkben (tehát a My_Custom_Something osztályt a classes/my/custom/something.php fájlban keresi). Ennek a működésnek van egy olyan előnye a 2.x-hez képest, hogy ott nem volt hova tenni a "business object"-eket, a libraries könyvtárba volt érdemes rakni őket (az volt egy olyan "egyéb" kategória az autoloadingba, amire semmilyen elnevezési konvenció nem vonatkozott), viszont a ilbraries-en belül nem lehetett alkönyvtárakat létrehozni - ezért aztán én 2.x-re nem is alapoznék igazán komoly projektet. A 3.x-ben a classes alatt azt csinálok amit akarok, így nincs ilyen gond. Szóval a 3.0 verzióban azt hiszem kinőtte a framework egy pár maradék gyermekbetegségét.

A sok egyszerűsítésnek egyébként meg is lett az eredménye a teljesítményben, eddig se volt egy erőforrás-igényes keretrendszer a kohana, de a 3.0 (install utáni) memória-fogyasztása ~1mb-ra csökkent (a 2.x-ben ez ~1.4mb) - örülünk.

Mivel a 3.0 verzió valójában nagyjából egy új framework-öt jelent, ezért még folytatják a 2.x sorozat fejlesztését is, szintén pár napja jött ki a 2.4 beta1, és úgy tűnik, nem sokáig lesz béta.

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.

Nem is olyan régen indult a jQuery UI projekt, mikor fél éve utoljára láttam, akkor még eléggé kezdeti állapotban volt, nem nagyon látszott, mi lesz belőle... bezzeg most...

Röviden egy javascriptes ablakozós libről van szó, desktop-szerű felületet lehet vele varázsolni webalkalmazásoknak (ilyen még pl. a Yahoo UI, stb) - max respect azoknak akik ilyen projektbe bele mernek fogni, elég szívás lehet.

Szóval a jQuery UI egy nagyon szép cucc, jól témázható, az eddigiek alapján jónak tűnik a dokumentációja, látszik, hogy van mögötte egy cég. Még egy úgynevezett ThemeRoller nevű appot is összehoztak, amivel egyszerűen össze lehet kattintgatni új témákat.

Tulajdonképp szépen fejlődik a javascriptes világ, minden negatívuma ellenére. Szerintem még egy jó darabig nem fogja átvenni a helyét a weben semmilyen RIA-technológia sem, sőt, inkább teljesen ki fognak szorulni a piacról (ami nem is baj).