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

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

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.

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

Nemrég megjelent a Java Servlet 3.0 API (JSR-315) final draft, tehát mostmár nem várhatóak túl nagy változások. A szervletek nagyon fontos részét képezik a Java EE platformnak, mivel sok már technológia - pl. JSP, JSF - alapját képezik.

A Servlet 3.0 -ban már az eddigi XML konfigurációs adatokat (web.xml) megadhatjuk annotációkkal is, ez persze nagyjából természetes, magától értetődő fejlesztés, és már régóta lehetett tudni, hogy ilyen lesz. Ami érdekesebb és én eddig nem hallottam róla, az az, hogy a szervletek aszinkron módon is működhetnek, ami nagyon jól jöhet, ha lassú erőforrásokra (pl. nagy adatbázisokra, távoli gépen futó webszolgáltatásra, stb) kell várnia az alkalmazásnak.

Az új API persze még nincs teljesen kész, és még nincs is adták ki hivatalosan, mint specifikációt. Ha kész lesz, utána kezdik csak el fejleszteni az implementációkat, úgyhogy még elég sokat kell várnunk arra, hogy kipróbálhassuk az új fícsöröket.

Megjelent a Zend Framework 1.8. A ZF - a kismillió php framework közül - talán a legfejlettebb és legkiemelkedőbb. Ha másért nem, legalább azért érdemes megemlíteni, mert a Zend cég fejleszti, akik a php nyelvet is karbantartják.

A ZF új verziója sok újdonságot hozott, olyanokat, melyeket én eddig nagyon hiányoltam. Ilyen például az alkalmazásunk struktúrájának felépítéséhez használható CLI, melyet a zf/bin/ könyvtárban találhatunk. Könnyen létrehozhatunk vele új projektet, azon belül új kontrollert vagy view scriptet. Fix fájlrendszert határoz meg a projektnek, ami szerintem szintén jó, nem szerettem, hogy eddig minden ZF tutorial-ban kicsit más volt a könyvtárstruktúra, más volt a .htaccess fájl, az index.php, stb. Új, objektum-orientált bootstrap került a frameworkbe, ez a Zend_Application osztály, így mostantól ez sem vesz el órákat új projekt kezdésekor.

Újratervezték az autoloader-t is (pontosabban jött egy új), mely képes különböző névterekhez különböző loadert rendelni, így kevesebb probléma van azzal, ha a projektünkben olyan komponenseket is használunk, melyek nem követik a Zend elnevezési konvenciókat.

A Google bejelentette az O3D projektet, ami egy JavaScript API 3D tartalmak böngészőn belüli megjelenítésére.

Nekem tetszik az ötlet, ha befut, akkor sokat dobhat a JavaScript - mint RIA platform - pozícióján. Tulajdonképp már régen megvolt a lehetőség egy ilyen fejlesztésre, hiszen a JS canvas nem mai találmány, csak nem nagyon van kihasználva. Az O3D böngészőplugin tartalmaz hardveres támogatást is, tehát nem a javascript motornak kell szoftveresen megoldani az összes számolást. Az API kulcsfogalma a scene graph, mely egy objektumhálóként (vagy faként) modellezi az ábrázolt teret, tehát más a megközelítés, mint mondjuk az OpenGL-nél, ez inkább a Java3D API-hoz hasonlít.

A pluginnek van egy olyan nagy előnye, hogy ad hardveres támogatást, és van egy olyan nagy hátránya, hogy fel kell telepíteni. Ez azért problémás, mert a JS csak azért indulhat versenyzőként RIA téren, mert nem kell hozzá plugin, bárhol fut, ahol böngésző van - tudásban persze nyilván nagyságrendekkel a flash, silverlight alatt áll. Szerintem ezért választotta a Google a javascriptet a saját webkettes alkalmazásai elkészítéséhez, és ezért nem fejlesztett saját technológiát (csak a JS-re húzta rá a GWT-t). Így sokkal gyorsabban és könnyebben szerzett felhasználói bázist (pl. sokkal kevesebben használnának gmail-t ha plugint kellene telepíteni hozzá). Az O3D ezt az előnyt sajnos nem élvezi.

Pofás kis script (ubuntu.hu -ról szedtem), gondoltam berakom, ha már 1x van :)

Ha esetleg vki be akarja ágyazni: