Keynoteok

Az Oracle részéről Mark Reinhold kezdte a Devoxx keynote-ot. Még egy piros pontot is összeszedett tőlem, mert (amire nem számítottam) már az első 5 slide-on volt forráskód.

Aztán Brian Goetz folytatta természetesen a Lambda Expressionökkel. Illetve először 1995-től kezdte, hogy kontextusba helyezze a Java történetét. És azt kell mondjam, hogy bármennyire is szkeptikus a természetem, nagyon meggyőzően beszélt a Java nyelvvel kapcsolatos döntésekről (sűrűn emlegetve James-t). Például az egyik mondás:

Reading core is more important than writing code.

És ha belegondolok, akkor ez – még ha lehet is rajta vitatkozni – egy érvényes hozzáállás. És ha ez az alapvető hozzáállásunk, akkor sokkal érthetőbb, hogy a Java miért olyan lomhán fejlődik, vagy hogy miért nem követi pl. a Scala útját. Ha elfogadjuk, hogy többször olvassuk a kódot mint írjuk, ezért a kód olvasása fontosabb, akkor azt is el kell fogadunk, hogy ebből a szempontból a Java-nak kétségtelen az előnye pl. a Scala-val szemben, amelyik inkább a frappánsabb leírásban erős, nem az egyszerű olvashatóságban.

Aztán persze jöttek a lambda expression-ök.

int heaviestGuy = people.ParalllelStream().filter(p -> p.getGender() == MALE).mapToInt(Person::getWeight).max();

És egy másik példa is az alapvetetések követésére: az tagadhatatlan, hogy a Java elég erős a visszafelé kompatibilitásban. Ha önmagában nézem azt a Java8 újítást, hogy default implementáció-kat adhatunk az interface-ekhez, akkor elég vegyesek az érzéseim. De ha az az kérdés, hogy hogyan lehet kiterjeszteni a Collection interface-t a fentiekkel a kompatibilitás megtörése nélkül, akkor már sokkal inkább egy ésszerű kompromisszumnak tűnnek az interface-be ágyazott kód darabkák

A Whats next szekcióban felmerül pl. a “value types”. A Java-t sokszor kritizálják, hogy nem minden objektum, hanem vannak primitív típusok. Brian szerint ezek épp hogy jók, csak az a baj, hogy nem lehet saját primitív típusokat definiálni. Ha lehetne ilyeneket, és pl. object header nélkül használhatnánk pehelysúlyú saját primitív típusokat is, akkor sok minden előtt megnyílnia az út, pl. lehetne Tuple-eket tisztességesen implementálni.

Ezek után jött Richard Bair és Stephen Chin, akik elhozták a JavaOne-on is demózott kütyüket. Egy Raspberry Pi alapú sakk robotot és egy Raspberry Pi (RPI) alapú home-made tabletet (DukePad). Ügyes kis kütyük kis döccenőkkel a demó is ment, mindegyiken Java fut.

Én a magam részéről kicsit szkeptikus vagyok a RPI-vel kapcsolatban. Az előadásban is felmerült, hogy egy RPI CPU ereje kb. tizede egy Samsung Galxy S4-nek. Viszont alig drágábban mint az RPI lehet kapni elég jó – akár a Samsung S4-es processzorokhoz is mérhető – ARM processzoros paneleket, amik még nyitottabbak is, csak kevesebb a hype körülöttük.

Továbbá az Internet of things dolgokra sokszor elég egy AVR (Arduino) vagy PIC. Amik nagyásgrendileg 2-8 dollárba kerülnek, és bár C-ben kell programozni, de Real Time dolgokra sokkal alkalmasabbak mint a Linux alapú RPI. Pl. egy I2C busz implementációt sokkal könnyebb szerintem C-ben programozni, mint Linux-ban debugolni, hogy a GPIO-k időzítése a kernelben és az APIn keresztül hol tart. Nem is beszélve, hogy AVR alapú kütyük akár egy évig elmennek egy gomb elemről…

Ennek ellenére, az RPI alapú Java nem felesleges erőfeszítés, mert ha RPI-n már fut elfogadható sebességgel a JVM, akkor a komolyabb ARM processzorokon is lesz értelme használni. (Más kérdés, hogy pl. egy szintén fillérekért kapható MIPS alapú házi routeren nem tudom, hogy mikor lesz JVM. Valószínű NodeJS hamarabb fog mindenhol futni.)