négyrétegű architektúra

A manageability blogban olvastam egy érdekes postot a rétegelt architektúrákról. A szerző a két vagy háromrétegű architektúra helyett négyrétegűt ajánl (lásd ábra). Az értelmét ennek az egésznek a SOA adja. Vannak régi rendszereink, amiket webszolgáltatásokba, vagy webes interfészekbe csomagoltunk. Ezektől adatokat igényelünk, de mindegyik más rendszer, így más a sebessége. Emiatt (a szerző szerint) szükség van a késleltetéseket kezelő Latency Engine-re. Ez hangolja össze az adatokat, és türelmesen vár, amíg minden beérkezik.
A késleltetés kezelésére többek közt azért sincs más módunk, mert a régi, működő rendszerekbe nem nyúlhatunk bele.
Az eredeti post egyébként Mark Nottingham Leveraging the Web for Services at Yahoo előadásából született. Én inkábbb a postot ajánlanám kezdetnek, mivel sokkal rövidebb.

rémi forax a parametrizált típusokról

Rémi Forax blogjában arról ír, hogy mi a probléma a típusparaméteres tömbökkel, és miért nem megengedett a definíciójuk. De nem csak a problémát veti fel: leírja, hogy a későbbiekben a nyelvi specifikációt hohyan lehetne átírni, hogy minden jó legyen.
Érdekes és rövid post.

újgenerációs java plugin technology

Pár napja az RSS olvasóm a next-generation java plugin technology bejegyzésektől volt hangos, utánenéztem hát, hogy mi is ez pontosan. Természetesen a JavaSE 6 legújabb update-jéről volt szó, vagyis arról, hogy milyen új funkciókat hozott magával. A release notes elolvasása után ezeket találtam a legfontosabbnak (illetve a leglátványosabbnak):

• Az appletek az új pluginnel kiemelhetők a browser ablakból, azaz egy kólön ablakot kaphatnak. Túlzottan nem mennék bele, azt ki lehet próbálni. Akit érdekel, hogy mi történik a sessionnel, az olvashat róla a java.net fórumon.
• Az appletek betöltése alatt látható kép lecserélhető (bár kinek ne tetszene a narancssárga kávé...). Ehhez az applet elem új paraméterét (centerimage) használhatjuk (ugyanúgy, mint a többbit: egy param elemben).
• JNLP támogatás. Az appleteket közvetlenül JNLP állományokból futtathatjuk - azaz az appletekből úgymond Java webstart alkalmazás lesz.

Az új lehetőségeket kitűnően bemutatják a NASA World Wind Java oldalon található appletek.

pénzdíjas Sun verseny diákoknak - érdemes

A Sun pénzdíjas versenyt indított diákoknak. A feladat egyszerű: véleményt alkotni az OpenSolarisról vagy a NetBeans 6.1-ről, és közzétenni (természetesen angol nyelven). A határidő június 6.
A díjak: 250 dollár nagydíj, illetve 5*100 dollár kisdíj. Erre rájön még a saját blog/honlap megnövekedett forgalma, ugyanis minden beadott művet a Sun honlapján közzé tesznek. Ráadásul ha nagyon jól sikerül, fel is figyelhetnek Rád.
A téma gyakorlatilag bármi lehet: tipp, pluginfejlesztés, benchmark stb. Csak a fantázia szab határt az ötleteknek.
Mindenkinek érdemes megpróbálni, aki viszonylag jól ír angolul. Én biztosan megpróbálom. Ha meg nem is gazdagszom, veszíteni biztos nem fogok.
A verseny szabályai.

mi várható a Java7-ben?

A Java rajongók népes tábora izgatottan várja, milyen újdonságokat hoz majd a Java7. Nézzük meg, mikről hallottunk eddig.

1. Mapekre alkalmazható for ciklus. A Java5 újdonsága volt a foreach szerű for ciklus. Ezzel egyszerűen járhatjuk be a kollekciókat, pontosabban az Iterable interfészt implementáló osztályokat. Sajnos a Map-re, mit speciális kollekcióra nem igazán lehet alkalmazni ezt a konstrukciót: vagy a kulcsok kollekcióját, vagy az elemekét járjuk be. A Java7-ben valószínűleg a for ciklust már Mapekre is használhatjuk, hasonlóan a PHP-hoz, valahogy így:
   
   for(String key, String elem: map){
   ...
   }
   
   Ezzel a ciklussal egyidejűleg járhatnánk be a kulcsokat és az elemeket, leegyszerűsítve a Map-ek bejárását.
2. Típusfelismerő for ciklus. Ez az újítás szintén a foreach ciklushoz kapcsolódik. Egy kollekció bejárásához jelenleg szükségünk van egy változóra, amelyben az aktuális elemet tároljuk. Azaz mindig meg kell adnunk a változó nevét és típusát. Ez az újítás egy kicsivel leegyszerűsítené a dolgunk azzal, hogy a típusmegadást elhagynánk. Ezt a fordító találná ki helyettünk a kollekció objektum típusából.
   
3. Szupercsomag. A szupercsomag egy teljesen új nyelvi konstrukció lenne. Lányege, hogy a csomagokat egy logikai egységbe szervezhetnénk, amelyen belül módosíthatnánk az egyes osztályok láthatóságát. Például megmondhatnánk, hogy egy adott csomag osztályait csak a szupercsomag többi csomagjának soztályai láthatják. Ezzel új lehetőségeket kapnánk az adatbezárás tökéletesebb kezelésére.
4. A C# properyjeihez hasonló konstrukció. Ezzel sokkal természetesebben érhetnénk el az egyes adattagokat (get és set metódusok hívogatása helyett), de az osztályok belső állapotához sem kellene nagyobb hozzáférést biztosítanunk. x.getField() helyett x.field-et írhatnánk. Aki ismeri a C#-ot (vagy a groovyt), az sejtheti, mire számíthatunk.
5. A dátum API cseréje. Erről korábban már írtam egy postot.
6. A konkurencia kezelése a nyelv részévé válhat, azaz kulcsszavakat vezethetnek be a többszálúság kezelésére.

A fentieken kívül még rengeteg dologról hallani, viszont ezek még nem mind kiforrottak, csak egyszerű lehetőségek. A szóba kerülő újításokról bővebben ezen a linken lehet tájékozódni. Én a fentieket találtam a legérdekesebbnek.

joda time és a Java API

Régóta tudjuk, hogy a Java dátumkezelése javításra szorul (a java.util.Date osztály már mejdnem minden metódusa használaton kívül helyezett, nem véletlenül). Mikor komolyabb dátumkezelésre volt szükségem, akkor találkoztam a JodaTime nevű open source komponenssel. Most azért találkoztam vele újra, mert szóba került, hogy a Java7-be bekerül a dátum keretrendszer.
A JodaTime teljes egészében a dátumkezelésre összpontosít (bár vannak más joda szoftverek is). Természetesen mindent tud, amit a Java Date és különböző Calendar osztályai, és valamennyire kompatibilis is azokkal. A Date osztály akkor vált elavulttá, mikor a dátumkezelés nemzetköziesítése szükségessé vált. Ennek támogatására új osztályokat vezettek be. A dátumkezelés osztályainak a többszálúsággal is meg kellett küzdeniük, azaz nem módosítható objektumokra volt szükség. A JodaTime szintén felkészült ezekre a kihívásokra, de jóval többet is tud. Nézzük, mik ezek pontosan:

• Dátumok kezelésének kifinomult támogatása. Erre a DateTime osztályt használhatjuk. Mindetn tud, ami a dátumkezeléshez szükséges. A dátumrengszeret (gregoriánus, juliánus stb.) egy másik osztály, a Chronology segítségével állíthatjuk be. Számos Chronology elkészült, illetve újak készíthetők. Mint majdnem minden osztály, a DateTime is nem módosítható, és hogy a leszármazottak se viselkedhessenek másképp, egyszerűen nem származtathatunk alosztályokat belőle.
  

• Időtartamok kezelse. Egy időtartam valamennyi ezredmásodpercet jelent, ahogy a neve is mutatja. Kezelésére a Duration osztály használhatjuk.
• Intervallumok beépített kezelése az Interval osztállyal.
• Parciális dátumok kezelése. Egy parciális dátum olyan dátum, amelynek nem ismerjük minden részletét. Ha például nem ismerjük az időzónát, akkor lokális dátummal van dolgunk. Ha nem ismerjük a dátumkomponenst, akkor egy időt reprezentáló objektumunk van. A parciális dátumok kezelését a Partial osztállyal valósíthatjuk meg.
• Több nap, hét, óra, perc stb. együttes kezelése. Ez hasznos lehet például akkor, ha öt napor (a munkanapokat) együttesen akarunk kezelni.
• Előre elkészített Comparator a dátumok hasonlításához.

A JodaTime mögött több éves fejlesztés áll. Ebből köetkezően egy nagyon kiforrott API-val van dolgunk, ami tényleg megérett arra, hogy a Java API részévé váljon. Kezelése nagyon egyszerű, ebben sokat segít a jó dokumentáció is. Nem kell attól sem tartanunk, hogy a jelenlegi Java dátumkezelés buktatóival találkozunk. Összességében érdemes már most áttérni a JodaTime használatára, ha komoly dátumkezelésre van szükségünk.
A komponens honlapján több bemutató példa is található, érdemes átnézni őket. Az API használatát viszonylag gyorsan el lehet sajátítani.

open source a JavaOne-on

Egy nappal az open source hibát boncsolgató bejegyzésem után Simon Phipps and Patrick Finch JavaOne előadásának összefglalója megjelent a Sun blogoldalán. Írnak benne az open source történetéről, természetesen a sunos ősőkre nagyon büszkék. Ezután áttérnek a jelenre, de a jövő a legérdekesebb. Megemlítik ugyanis, hogy a Gartner előrejelzése szerint 2010-re a szoftverek 90%-a open source alapokon fog állni (azaz pl. open source komponensekből építik fel). Remélhetőleg a fennmaradó 2 év alatt javul a nyíltforrású színvonal. A cikk végén beszélnek a jövőbeli khívásokról (licenszing stb.)
Érdekes cikk, hiteles szerzők. Érdemes elolvasni.