Das Javaforum ist ja doch schon eine Weile her – höchste Zeit, das Erlebte und Gehörte zumindest in Stichworten festzuhalten. Wie jedes Jahr war das Javaforum eine interessante Veranstaltung, für Javaentwickler aus dem Raum Stuttgart einfach ein Pflichttermin.

vert.x: Polyglott, modular, asynchron

Der Tag begann vielversprechend mit einem Einstiegsvortrag in vert.x (Folien hier). vert.x ist ein ereignisgetriebenes Anwendungsframework. Dabei versucht vert.x, durch entsprechende Bindings möglichst viele Sprachen zu bedienen: Momentan sind es Java und Groovy, in Bälde kommen Scala, Clojure und einige weitere hinzu.

Der meiner Meinung nach spannenste Aspekt ist die Modularisierung: Module („Verticles“) kommunizieren untereinander mittels JSON-Nachrichten und lassen sich unabhänig voneinander beliebig starten, stoppen, aktualisieren – und das (angeblich) einfacher und unkomplizierter als mit Frameworks wie OSGi.

Über die technischen Details des Unterbaus konnte ich leider nichts näheres erfahren. Ich wäre neugierig gewesen, ob man hier wieder einmal das Rad neu erfunden hat, oder ob man sich auf bestehende Bibliotheken zurückgezogen hat. Insbesondere beim Message Bus und beim Clustering kann es leicht haarig werden, da würden ein paar robuste Bibliotheken ein angenehmes Gefühl der Stabilität und Zuverlässigkeit vermitteln.

Nicht abschließend überzeugt hat mich die „lose Kopplung“ mittels JSON-Nachrichten. Das Framework bietet laut dem Vortrag hier keine Unterstützung für das Aushandeln und Garantieren von Schnittstellen oder Nachrichtenformaten. Das bedeutet im Umkehrschluß, daß ein Tippfehler beispielsweise in einem Feldname eine Applikation brechen kann, und daß ein solcher Fehler erst zur Laufzeit entdeckt werden kann. Ebenfalls etwas skeptisch bin ich bezüglich der Codepflege. Sämtliche vert.x-Vorgänge laufen asynchron, über das Ergebnis wird man mittels Callbacks benachrichtigt. Möchte man naiv hiermit einen linearen Programmablauf umsetzen, beginnt man, den Callback im Callback im Callback zu implementieren – selbst mit Java-8-Lambdas dürfte das recht häßlichen Code ergeben. Eine Verkettung, wie es beispielsweise die Futures von Akka bieten, wurde nicht vorgestellt.

Integrity Acceptance-Test-Automatisierung

Dieser Vortrag stellte Integrity, ein Tool zum Erstellen von Akzeptanztests, vor. Integrity bietet eine DSL zum Schreiben der Testfälle plus eine Einbettung in Eclipse mit Ausführen der Tests, Ergebnisanzeige und passendem Editor. Bis dato hatte ich noch keinen Bedarf hierfür, dennoch sieht das Projekt sehr ansprechend aus, ich werde es im Hinterkopf behalten.

Sicherheitsprobleme in Webanwendungen

Auch dieses Jahr durfte ich wieder einen Vortrag halten :-) In diesem Jahr hatte ich mir das Thema Security in Java-Webanwendungen vorgenommen (Folien hier). Statt eines breiten Überflugs wollte ich die Themen Injection, Cross-Site-Scripting und Authentisierungs-/Session-Probleme beleuchten. Das Thema stieß auf ordentlich Resonanz, der Vortrag fand in einem der größten Säle statt und war gut gefüllt, wie das Foto zeigt:

Visuelle Codeanalyse

Code visuell aufbereiten und an solchen Grafiken Strukturen oder Designprobleme erkennen – das waren die Gedanken, mit denen ich in den Vortrag ging. Der Vortrag stellte mehrere Tools vor, welche alle stadtplan-artige Grafiken erzeugten (auf der Webseite von CodeCity zu sehen). Irgendwie erschloß sich mir daraus nicht der große Gewinn. Hinweise, wie man solche Grafiken zu lesen hätte, in welchen Situationen sie helfen und wie man das Lesenlernen angeht, gab es kaum. Schade.

Twitter Storm

Das in diesem Vortrag vorgestellte Storm ist ein Framework zum Erstellen verteilter, skalierbarer Anwendungen. In vielen Belangen ähnelt es Aktoren-Frameworks, ist aber in seiner Einsetzbarkeit spezieller – was bedeutet, daß Aktorenframeworks einerseits generischer sind, andererseits Storm dafür leicher zu konfigurieren ist. So war jedenfalls mein Eindruck, dieser Blogartikel vergleicht Storm und Akka und kommt zu einer ähnlichen Schlußfolgerung.

Storm fokussiert sich auf pipeline-artige Abläufe, Map-Reduce-Vorgänge dürften ein Paradebeispiel dafür sein. Der Beispielcode des Vortrags filterte die Eingabe aus der Twitter Streaming-API nach bestimmten Hashtags und trug die Ergebnisse in eine Statistik ein. Mein Eindruck: Kann unter Umständen praktisch sein, insbesondere wenn die zu lösende Aufgabe zum Framework paßt und das Entwicklerteam noch keine Erfahrung mit Aktoren gesammelt hat.

Der kleine BASE-Survival-Guide

Das „Finale Furioso“ legte Uwe Friedrichsen mit seinem Vortrag über BASE (Basically Available, Soft state, Eventually consistent) Datenbanken hin. In einem vermeintlich einfachen Beispiel (kann sehr gut anhand der Folien nachvollzogen werden) zeigte er die Fallstricke und Probleme beim (naiven) Einsatz von NoSQL-Datenbanken. Für alle, die an Aufgaben mit einem simplen „dann nehmen wir halt mal NoSQL statt SQL“ herangehen wollen, ein echter Augenöffner… das CAP-Theorem läßt sich eben nicht betrügen ;-)

Von der „NoSQL matters“ gibt es einen Vortragsmitschnitt, soweit ich das sehe, ist das derselbe Vortrag auf Englisch. Ansehempfehlung meinerseits, Uwes Vortrag war für mich das Highlight des diesjährigen Javaforums.

Bildquelle: JUGS G+-Galerie