Élő közvetítés a JavaOne-ról JavaOne - Frissen, élőben

De nem message queue, hanem emberi. A Moscone szuper-organizált sorbanállásai után (ahol a táblás "robotok" kiabálással is segítik, hogy mindenki bambán is a jó sorba álljon (tri-o-seven here)) kicsit szokatlan volt a párizsi reptér, ahol egy kapunál két gépre kellett egyszerre beszállni, és a nizzaiakat mindig hátraküldték a sor elejéről, a budapestiek meg nem jutottak oda a pulthoz a nizzaiaktól, és 80 fok meleg volt a csodás, új üveg, terminálépületben. És a cső középen elágazik, és akkor még lehet véletlenül rossz gépbe is szállni. Fél óra késéssel aztán sikerült mindenkit a gépébe szortírozni.

Illetve vége van, de én még tartozom pár beszámolóval. Mondjuk azt, hogy a repülőn megírom, otthon feltöltöm, és akkor mindenki munkanap elolvassa hétfőnkedden. Ki, mikor dolgozik. 

És fotóztam is ma még, azok is várhatók. Nehéz dolog ez. Mármint laptopot, fényképezőgépet és csomó papírt cipelni egész nap. 

Az a terv, hogy ide még majd írok java érdekességeket később is. Van ez a terv. Vannak nagyobb szabású terveim is. A holland Java Users Group (.nlJUG) annyira jelen volt, hogy azon gondolkoztam, miért nincs huJUG? Vagy ha van, akkor én miért nem tudok róla. Nem tudom, mivel jár JUG-nak lenni, de gondolom, előnyös. A hollandok nyolcvanan voltak kint a konferencián. Jó, persze attól, hogy JUG vagyunk, nem biztos, hogy egyből milliomosok is leszünk, de biztos meghívhatjuk a hírességeket.

A JavaCaféra feltétlenül gyertek, hogy legyen kinek elmesélni szóban a konferenciát, és rákérdezni azokra, amiket a véges gépelési sebességem miatt nem írtam be, mondták is, hogy időnként kicsit címszavas a blog. 

Fura volt egy hetet a föld alatt tölteni, de a Moscone center már csak ilyen.  Voltak előadások az utca alatt is, a két épület között. Google Map. Én rányomnék a Street View gombra is. 

lásd a Péntek General Session bejegyzésben. Ami kimaradt: pluginelhető, például van hozzá Glassfish plugin, amellyel az appserver belseje is monitorozható (deployolt alkalmazások, servletek hány szálon, stb). Ami ebben tetszik, hogy néhány appserver gyárosnak ehhez ÓRIÁSI infrastruktúra kell/van, itt meg az egész egy 7M-s alkalmazás.

A fő dizájn ember tartotta. Elég száraz volt dizájn/használhatóság/ergonómia előadásnak. Nem tudtam meg semmit. Kell prototípus (megmondta, hogy ez vagy papír, vagy html/swing). Kell feedback a userektől. Stb. De legalább jó hamar abbahagyta, most tudok blogolni.

Tegnap láttam BMW Z3 kabriót. Mozgássérült-igazolvánnyal.

Legnagyobbrészt egy demo töltötte ki, volt évfolyamtársam tartotta. Jobban beszél angolul, mint a Session-házigazda vice president :-). 

Maga a demo arról szólt, hogy az Oracle egybeolvaszja a Webcentert (ez az aktuális, 100% Java portlet containerük) a JSF-et (amihez az ADF Faces nevű csomagot ajánlják, (az ADF részben open source, de részben fizetős)) és mindehhez a JDeveloper ad varázslókat development time, plusz a weben minden konfigurálható run time. És van benne magic, amitől az instant üzengetés, az adatbázis, a HR, mások portaljai, a Web2.0, a flicker és minden egybeolvad, és a sales ember csak úgy ezen át mindent megold.

Marha látványos volt, minden működött, mint a varázslat, nem láttuk viszont, hogy mi van mögötte.

Aztán bejelentették, hogy az Oracle is megírta a maga Eclipse-plugin készletét (ahogy az IBM, meg a myeclipse open source, stb), hiszen maga az Eclipse csak egy "buta" IDE (vagy "okos szövegszerkesztő), és ráadásul Oracle supportálja, viszont ingyenes, sőt open source. Ez mondjuk jó, eddig ilyen nem volt.

 

Aztán kicsit beszéltek a Gridről, és a diagrammokon minden komment nélkül Weblogic meg JRockit szavak voltak.

Hááááát. 7.30-tól 9.30-ig tartott, erre mondják, hogy not really much of a party. Kint volt a Moscone mögött/fölött a Yerba Buena Gardenben. Fellépett a gitározó, üvöltő, fejrázó együttes 8-tól kilencig. Volt vagy 10 fok, jó nagy szél. Iszonyú hosszú (de nagyon gyors) sor a Moscone pincéjéből, fel, körbe a ház körül, be a kertbe. Ittünk egy sört (megmaradt a másik drink kuponom), megfagytunk, hazamentünk.

Eközben a certified java professional-oknak (tessék vizsgázni, megéri) tartott fogadásról (James Goslinggal és open barral) lekéstünk, mert akkor is bent ültünk előadáson. :(

Az első demo a VisualVM nevű eszköz. Bár néhány meglévő cuccból rakták össze, mégis nagyot dob szerintem a Java monitorozáson. Gyakorlatilag egy grafikus keretrendszer, amelyben benne van a JConsole (JMX-felület), a VisualGC/jvmstat (memóriamonitor, szemétgyűjtésmonitor), a néhai JFluid (később Netbeans Profiler). Egyben. Futtatható Netbeans pluginként is, meg azon kívül is. visualvm.dev.java.net instant musthave

Következett a Netbeans JavaScript editor. Mindenféle jóságokat tud, kiegészít, kontextus-szenzitív menük, js könyvtárak tartalmát is használja a kiegészítő. Potenciális hibákat listába gyűjti, színezi, például globális változó használatát függvényben. A kódkiegészítő tudja minden függvényről, és kis ikonokkal jelzi, hogy melyik böngészőben működik. Firefox pluginnel lehet Netbeansből debugolni (hamarosan IE plugin is jön).

Aztán NVIDIA openGL hardware: demo: mobil telefonon 3D animáció sztereo hanggal.

Project Darkstar: online játék szerver platform (tkp. egy appserver), skálázódik. Mellesleg jMonkey játék-kliens engine - nem csak játékra, építész (Gosling bátyja) modellez vele, NASA is használja 3D megjelenítésre.

Javacard3: chipkártya, melyen JavaVM fut. Volt a múlt héten egy vetélkedő: a kártyán http szerver futott, kellett rá írni tank-vezérlő szoftvert. Utána a játékosok bedugták a szerverbe a kártyájukat, és a két tank harcolt. A végső nyertes most kapott egy Playstation 3-at. Egyébként a Londoni tömegközlekedés Oyster kártyája is JavaCard (régebbi verzió), a kártyán fut a díjszámító algoritmus, ezért nem kell az állomások között annak a rengeteg utazónak az összes kapuátlépését real time mozgatni.

Sentilla java chip: 256kbps rádiókapcsolat, 1M storage, 10k ram. CLDC 1.1, SentillaVM. Van rajta 8 AD-DA átalakító szenzoroknak és vezérlőknek. Van USB kapcsolat. A demo nagyon látványos volt, strandlabdákba raktak ilyent, a közönség dobálta őket. A chipek kiépítették a hálózatot (mesh network) egymással és a terem sarkaival, és a kivetítőn lehetett látni a labdák pozícióját. Felmerült még a hőmérős, súlymérős söralátét-hálózat, a pincérek tudják, hova kell sört vinni. :-)

Volt egy ipari PC: BlueWonder néven. x86 processor, Solaris, Real-time Java, 2000 I/O port. Demo: önjáró autó, ezzel nevez a Sun csapata a DARPA Urban Challenge-re. Aki nem tudja mi az: 60 mérföldet kell az autónak megtenni valódi városban. Egyedül. 2 millió dollárt lehet nyerni.

A CERN is bemutatta, hogy a részecskegyorsító körül minden Java, a folyamatirányítástól a tűzjelzőn át (BPEL process) az adatmegjelenítésig. Adatmennyiség: 2 petabyte /sec (= 3 millió CD másodpercenként). 

http://www.theserverside.com/news/thread.tss?thread_id=49332

Jó hosszú beszámoló. Most mindjárt megyünk az utolsó Global Sessionre, James Gosling tartja.  

kommentekre válaszok:

talalkozzunk ossze barkivel a konferencian. aki ir mailt (sngeza@gmail.com), annak megmondom az itteni mobilszamom.

javase6 update10: valojaban beta verzio van csak. letoltheto, ha a google-be ezt irjatok (gyk: javase 6 update 10 download) 

blueray specko: nemtom, hogy letoltheto-e. google. majd en is nezem 

alapvetoen ket fél eloadas. EAI patterns java caps demo

Először volt egy rövid összefoglalás a JBI 1.0-ról. Container of containers (JBI-be beteszem a kül. service engine-eket (BPELSE, XSLTSE, rulesSE, ...), és azok sokszor maguk is containerek, beléjük teszem a service unitokat (egy bpel processzt, egy xsl-t, egy szabályt stb).

JBI 2-t mostanra ígérték, de még nincs kész a speckó. Valamelyik nap azt mondta valaki, hogy vártak, amíg az ipar egyáltalán kicsit felpickupolja ezt a technológiát, kiderülnek a tanulságok, és akkor lehet jó, új verziót csinálni. Ma már van kb. 5 JBI implementáció a világon.

JBI 1.0: too small, too big, no API, not distributed, WSDL/XML-alapú

JBI 2.0 = JSR 312: expert group: Sun, Software AG, BEA (=Oracle), IBM, JBoss (=RedHat), Apache, Adobe, CapGemini, IONA, stb.

Új fícsörök:

- átorganizálják a speckót, hogy kül. hallgatóságoknak is jó legyen (jelenleg SE- és BC-fejlesztőknek szól főleg)

- alternatívák a WSDL interface-leíráson kívül

- POJO komponensek lehessenek

- JAX-WS/EJB/Spring/stb

- nem-XML üzenetek mehessenek, streaming!!!

- interceptorok 

- OSGi (ez a varázsszó az idén)

Ami az elosztottságot illeti: nem része a speckónak. A gyártók oldják meg / megoldhatják / meg fogják oldani. Ez egyfelől nemn akkora katasztrófa (miért, a JavaEE sem mondja ki, hogy muszáj clusterezhetőnek lenni az appservernek), másfelől pusztán a realitás. Sok gyártó nyomja a sok régi middleware-jét, és nyilván mindben tök másképp van ez megoldva. És nem lehetett egyezségre jutni az expert groupban.

Egyelőre nincs határidő, kész lesz, amikor kész lesz. Ez egy implementation-lead speckó, azaz folyamatosan írják a referenciaimplementációt, és közben alakul a szabvány. Tervezik, hogy csinálnak publikus website-ot, publikus levlistát. Egyelőre a JCP-s belsőt használják, ezért a kívülállók nem látják a haladást.
 

még hátravan tegnapról: jbi2.0, real world soa (discounttires.com), WS-SX (web services security exchange)

Résztvevők: többek közt IBM, RedHat, Peter Walker (JBI spec lead, Sun), CapGemini, vezette egy ex-Microsoft-Sun ember

A téma a Service Component Architecture (SCA) volt, a default leírónyelv: SCADL (ejtsd: skiddle).
Tanulság, nagyon csodás, nagyon minden összekapcsolható (Ruby, JavaEE, Spring, ...), de. De csak azért, mert valaki megírta ezeket az összeköttetéseket, igen, páronként minden és minden közé. És erre semmit nem mond a szabvány, tehát majd jól lesznek gyártófüggő (vagy opensource-csapat-függő), úgy mondták: ökoszisztémák, és nem igazán dobom át egyikből a másikba azokat a bizonyos összekapcsoló-varázslatokat. Vesd össze JBI: ahol a központi sín (ESB) szabványos, és elvileg egyik gyártó ESB-jére simán rádugjuk a másik gyártó BPEL motorját, meg a sok többiek kölünböző BC-it (binding component, ez beszél mondjuk SOAP-ot, JMS-t, EJB-t stb.)
 

Sok új, apró annotáció, mind iszonyú hasznos, például:
- Embedable osztályban @AttributeOverride megmondhatja a tényleges oszlopnevet.
- @AssociationOverride
- OneToMany esetén mondhatjuk, hogy @OrderBy, és ekkor a one.getMany() -szerű hívások már rendezve adják vissza a listát a detail táblából
- vagy @OrderColumn deklarálja, hogy legyen konkrét oszlop erre a célra (volt ilyen mondat, hogy ezzel óvatosan bánni, sokszor az @OrderBy inkább jó)
Automatikus orphan detection: azaz, kapcsolt táblák (kapcsolt entitások) esetén ha már nincs meg a master rekord, akkor magától az EntityManager kidobálja a detail rekordokat is!!! Szemétgyűjtés az adatbázisban!
Pessimistic locking - egyelőre itt még folyik a vita az expert groupban, hogy pontosan mikor mit lockoljon.
Új property-k és hintek, például locktimeout, querytimeout.
A cache téma is felmerült (ugye, Toplink cluster), lesz API, például rákérdezhetünk, hogy contains() ?