Das Ja­va­fo­rum ist ja doch schon eine Weile her – höchs­te Zeit, das Er­leb­te und Ge­hör­te zu­min­dest in Stich­wor­ten fest­zu­hal­ten. Wie jedes Jahr war das Ja­va­fo­rum eine in­ter­es­san­te Ver­an­stal­tung, für Ja­va­ent­wick­ler aus dem Raum Stutt­gart ein­fach ein Pflicht­ter­min.

vert.x: Po­ly­glott, mo­du­lar, asyn­chron

Der Tag be­gann viel­ver­spre­chend mit einem Ein­stiegs­vor­trag in vert.x (Fo­li­en hier). vert.x ist ein er­eig­nis­ge­trie­be­nes An­wen­dungs­frame­work. Dabei ver­sucht vert.x, durch ent­spre­chen­de Bin­dings mög­lichst viele Spra­chen zu be­die­nen: Mo­men­tan sind es Java und Groo­vy, in Bälde kom­men Scala, Clo­ju­re und ei­ni­ge wei­te­re hinzu.

Der mei­ner Mei­nung nach span­nens­te As­pekt ist die Mo­du­la­ri­sie­rung: Mo­du­le („Ver­ti­cles“) kom­mu­ni­zie­ren un­ter­ein­an­der mit­tels JSON-Nach­rich­ten und las­sen sich un­ab­hä­nig von­ein­an­der be­lie­big star­ten, stop­pen, ak­tua­li­sie­ren – und das (an­geb­lich) ein­fa­cher und un­kom­pli­zier­ter als mit Frame­works wie OSGi.

Über die tech­ni­schen De­tails des Un­ter­baus konn­te ich lei­der nichts nä­he­res er­fah­ren. Ich wäre neu­gie­rig ge­we­sen, ob man hier wie­der ein­mal das Rad neu er­fun­den hat, oder ob man sich auf be­ste­hen­de Bi­blio­the­ken zu­rück­ge­zo­gen hat. Ins­be­son­de­re beim Mes­sa­ge Bus und beim Clus­te­ring kann es leicht haa­rig wer­den, da wür­den ein paar ro­bus­te Bi­blio­the­ken ein an­ge­neh­mes Ge­fühl der Sta­bi­li­tät und Zu­ver­läs­sig­keit ver­mit­teln.

Nicht ab­schlie­ßend über­zeugt hat mich die „lose Kopp­lung“ mit­tels JSON-Nach­rich­ten. Das Frame­work bie­tet laut dem Vor­trag hier keine Un­ter­stüt­zung für das Aus­han­deln und Ga­ran­tie­ren von Schnitt­stel­len oder Nach­rich­ten­for­ma­ten. Das be­deu­tet im Um­kehr­schluß, daß ein Tipp­feh­ler bei­spiels­wei­se in einem Feld­na­me eine Ap­pli­ka­ti­on bre­chen kann, und daß ein sol­cher Feh­ler erst zur Lauf­zeit ent­deckt wer­den kann. Eben­falls etwas skep­tisch bin ich be­züg­lich der Code­pfle­ge. Sämt­li­che vert.x-Vor­gän­ge lau­fen asyn­chron, über das Er­geb­nis wird man mit­tels Call­backs be­nach­rich­tigt. Möch­te man naiv hier­mit einen li­nea­ren Pro­gramm­ab­lauf um­set­zen, be­ginnt man, den Call­back im Call­back im Call­back zu im­ple­men­tie­ren – selbst mit Ja­va-8-Lamb­das dürf­te das recht hä­ß­li­chen Code er­ge­ben. Eine Ver­ket­tung, wie es bei­spiels­wei­se die Fu­tures von Akka bie­ten, wurde nicht vor­ge­stellt.

In­te­gri­ty Ac­cep­tan­ce-Test-Au­to­ma­ti­sie­rung

Die­ser Vor­trag stell­te In­te­gri­ty, ein Tool zum Er­stel­len von Ak­zep­tanz­tests, vor. In­te­gri­ty bie­tet eine DSL zum Schrei­ben der Test­fäl­le plus eine Ein­bet­tung in Eclip­se mit Aus­füh­ren der Tests, Er­geb­nis­an­zei­ge und pas­sen­dem Edi­tor. Bis dato hatte ich noch kei­nen Be­darf hier­für, den­noch sieht das Pro­jekt sehr an­spre­chend aus, ich werde es im Hin­ter­kopf be­hal­ten.

Si­cher­heits­pro­ble­me in Web­an­wen­dun­gen

Auch die­ses Jahr durf­te ich wie­der einen Vor­trag hal­ten :-) In die­sem Jahr hatte ich mir das Thema Se­cu­ri­ty in Ja­va-Web­an­wen­dun­gen vor­ge­nom­men (Fo­li­en hier). Statt eines brei­ten Über­flugs woll­te ich die The­men In­jec­tion, Cross-Site-Scrip­t­ing und Au­then­ti­sie­rungs-/Ses­si­on-Pro­ble­me be­leuch­ten. Das Thema stieß auf or­dent­lich Re­so­nanz, der Vor­trag fand in einem der grö­ß­ten Säle statt und war gut ge­füllt, wie das Foto zeigt:

Vi­su­el­le Code­ana­ly­se

Code vi­su­ell auf­be­rei­ten und an sol­chen Gra­fi­ken Struk­tu­ren oder De­sign­pro­ble­me er­ken­nen – das waren die Ge­dan­ken, mit denen ich in den Vor­trag ging. Der Vor­trag stell­te meh­re­re Tools vor, wel­che alle stadt­plan-ar­ti­ge Gra­fi­ken er­zeug­ten (auf der Web­sei­te von Co­de­Ci­ty zu sehen). Ir­gend­wie er­schloß sich mir dar­aus nicht der große Ge­winn. Hin­wei­se, wie man sol­che Gra­fi­ken zu lesen hätte, in wel­chen Si­tua­tio­nen sie hel­fen und wie man das Le­sen­ler­nen an­geht, gab es kaum. Scha­de.

Twit­ter Storm

Das in die­sem Vor­trag vor­ge­stell­te Storm ist ein Frame­work zum Er­stel­len ver­teil­ter, ska­lier­ba­rer An­wen­dun­gen. In vie­len Be­lan­gen äh­nelt es Ak­to­ren-Frame­works, ist aber in sei­ner Ein­setz­bar­keit spe­zi­el­ler – was be­deu­tet, daß Ak­to­ren­frame­works ei­ner­seits ge­ne­ri­scher sind, an­de­rer­seits Storm dafür lei­cher zu kon­fi­gu­rie­ren ist. So war je­den­falls mein Ein­druck, die­ser Blo­g­ar­ti­kel ver­gleicht Storm und Akka und kommt zu einer ähn­li­chen Schluß­fol­ge­rung.

Storm fo­kus­siert sich auf pipe­line-ar­ti­ge Ab­läu­fe, Map-Re­du­ce-Vor­gän­ge dürf­ten ein Pa­ra­de­bei­spiel dafür sein. Der Bei­spiel­code des Vor­trags fil­ter­te die Ein­ga­be aus der Twit­ter Strea­m­ing-API nach be­stimm­ten Hash­tags und trug die Er­geb­nis­se in eine Sta­tis­tik ein. Mein Ein­druck: Kann unter Um­stän­den prak­tisch sein, ins­be­son­de­re wenn die zu lö­sen­de Auf­ga­be zum Frame­work paßt und das Ent­wick­ler­team noch keine Er­fah­rung mit Ak­to­ren ge­sam­melt hat.

Der klei­ne BA­SE-Sur­vi­val-Gui­de

Das „Fi­na­le Fu­rio­so“ legte Uwe Fried­rich­sen mit sei­nem Vor­trag über BASE (Ba­si­cal­ly Avail­able, Soft state, Even­tual­ly con­sis­tent) Da­ten­ban­ken hin. In einem ver­meint­lich ein­fa­chen Bei­spiel (kann sehr gut an­hand der Fo­li­en nach­voll­zo­gen wer­den) zeig­te er die Fall­stri­cke und Pro­ble­me beim (nai­ven) Ein­satz von NoS­QL-Da­ten­ban­ken. Für alle, die an Auf­ga­ben mit einem sim­plen „dann neh­men wir halt mal NoSQL statt SQL“ her­an­ge­hen wol­len, ein ech­ter Au­gen­öff­ner… das CAP-Theo­rem läßt sich eben nicht be­trü­gen ;-)

Von der „NoSQL mat­ters“ gibt es einen Vor­trags­mit­schnitt, so­weit ich das sehe, ist das der­sel­be Vor­trag auf Eng­lisch. An­seh­emp­feh­lung mei­ner­seits, Uwes Vor­trag war für mich das High­light des dies­jäh­ri­gen Ja­va­fo­rums.

Bild­quel­le: JUGS G+-Ga­le­rie