Java Forum Stuttgart 2016

Das Jahr 2016 entwickelt sich für mich zu dem Jahr mit den bisher meisten Konferenzbesuchen. Nach den Voxxed Days in Berlin im Januar, der JavaLand im März und der building IoT im Mai stand im Juli das Java Forum Stuttgart auf dem Programm. Nach mehreren Anläufen habe ich es in diesem Jahr endlich geschafft die Veranstaltung zu besuchen.

Die von der Java User Group Stuttgart organisierte eintägige Konferenz fand in diesem Jahr zum 19. Mal statt. Wie auf jeder Konferenz hatte ich in jedem Slot die Qual der Wahl welchen Vortrag ich mir anschauen möchte. Bereits im Vorfeld hatte ich eine Auswahl getroffen, die praktischerweise auch auf meinem Ausweis aufgedruckt war.

Neues von JUnit: Architektur, API und Erweiterbarkeit in der Version 5

Ich habe mich an der Crowdfunding Kampagne zur Weiterentwicklung von JUnit im Jahr 2015 beteiligt. Anfang diesen Jahres konnte ich bereits die ersten Neuerungen in Blogbeiträgen erfahren. Der Vortrag von Marc Philipp und Matthias Merdes war die Gelegenheit sich endlich intensiver mit der in diesem Jahr erscheinenden neuen Version von JUnit zu beschäftigen.

Zu Beginn des Vortrags stellte Marc Philipp die neue Architektur von JUnit 5 vor. Innerhalb der Platform findet die eigentliche Ausführung der Unit-Tests statt. Die Kontrolle der Ausführung wurde von der eigentlichen Ausführung entkoppelt. Somit müssen IDEs und Build-Tools nichts mehr über die Ausführung wissen.

Die Plattform nutz verschiedene “Laufzeitumgebungen” für Tests. Neben der Vintage genannten Umgebung für JUnit Tests vor der neuen Version 5 gibt es die neue Jupiter genannte Umgebung. In dieser Umgebung finden sich alle Neuerungen für die Programmierung von Tests.

Es gibt verschiedene neue Annotationen mit denen z.B. eine ausführliche Bezeichnung von Testklassen und Tests gesetzt werden kann. Über @Tag können Tests markiert und anschließend nur mit einem bestimmten Tag versehene Tests ausgeführt werden. Interessant ist auch die Möglichkeit Tests zu verschachteln. So können Test mit einer gemeinsamen “Vorgeschichte” in einer Unterklasse gesammelt werden. Mit der Annotation @TestFactory steht ein interessanter Mechanismus zur dynamischen Erstellung von Tests zur Verfügung. Im Vortrag erwähnten Marc und Matthias noch viele weitere Mechanismen und Annotationen, die am besten den Folien entnommen werden können.

Spark vs. Flink - Rumble in the (Big Data) Jungle

Einen unterhaltsamen Vergleichen zwischen den Big Data Frameworks Spark und Flink stellten Konstantin Knauf und Michael Pisula vor. Sie verglichen anhand einer praktischen Aufgabe die beiden Frameworks aus dem Apache Projekt. So musste in beiden Framework sowohl eine Batch- als auch eine Stream-Verarbeitung umgesetzt werden. Weiterhin sollten bestehende Daten zur Analyse herangezogen werden.

Vorteil von Flink ist dabei, dass es ein “echtes” Streaming Framework ist. Spark hingegen realisiert Streams durch Micro Batches. Die gestellte Aufgabe konnte von beiden Framework realisiert werden. Jedes Framework hat dabei in einzelnen Bereichen seine Stärken und Schwächen.

Die Antwort welches Framework das bessere ist, kann nur mit einem klaren “it depends” beantwortet werden. Für die eigene Entscheidung sollten dabei auch die Größe der Community mit berücksichtigt werden.

Für das konkrete Projekt wurde von den Beiden Apache Flink gewählt.

Klappe auf! Was macht die JVM denn da?

Sehr viel mitnehmen konnte ich vom Vortrag von Tobias Frech. Er stellte in seinem Vortrag die verschiedenen Werkzeuge des JDK vor, mit denen man Laufzeitproblemen auf den Grund gehen kann.

Nach einer kurzen Beschreibung der Tools jps, jinfo, jstat, jstack, jmap und dem zukünftigen Allrounder jcmd beschrieb Tobias am Beispiel eines konkreten Szenarios deren Einsatz. Mittels Elastic Search wurden die Panama Papers nach bestimmten Personen durchsucht. In der ersten Konstellation lief Elastic Search unter dem (Open)JDK 7. Mittels der Befehle zeigte Tobias den Speicher- und CPU-Verbrauch.

Nun wurde die Umgebung unter (Open)JDK 8 gestartet. In dieser Konstellation wurde ein wesentlich niedriger Durchsatz erreicht. Mittels der Befehle konnte das Bottleneck im Just-In-Time Compiler gefunden werden. Eine Erläuterung der Ursache und Hinweise zur deren Behebung liefert viele interessante Informationen über die Konfiguration der Java Virtual Machine.

Es lohnt sich auf jeden Fall die Folien von Tobias als Grundlage für das weitere Erforschen der JVM-Tools zu nutzen.

MonitoringMetrics 101 - Leveraging on the Power of JMX

Eine Einführung in das Monitoring von Systemen mittels JMX gab Martin Gutenbrunner in seinem Vortrag. Zu Beginn stellte Martin die Unterschiede zwischen Debugging und Monitoring dar. Auch ging er auf die Unterschiede zwischen aktivem Monitoring (JMX) und passivem Monitoring (z.B. Icinga) ein. Danach folgte eine kurze Beschreibung der Geschichte von JMX. Eine Liste mit möglichen JMX Quellen durfte nicht fehlen. Hier kann man feststellen, dass so gut wie alle in der Java Welt eingesetzten Technologien bereits entsprechende MBeans mitbringen.

Interessant waren die Erläuterungen zur Nutzung von JMX. Dabei wurden die Anforderungen an eine Monitoring aus Sicht von Entwicklern (Dev), dem Betrieb (Ops) und der Fachanwender (Business) beschrieben. Für alle Zielgruppen stellte Martin Metriken vor, mit denen Aussagen zum Zustand des Systems für die jeweilige Zielgruppe getroffen werden können. Mit einem interessanten Ausblick auf weitere Techniken zum Monitoring endete der Vortrag.

Apache Kafka - Skalierbare Nachrichtenverarbeitung und mehr!

Guido Schmutz stellt in seinem Vortrag den Message Broker Apache Kafka vor.

Sehr schön fand ich dabei die Überleitung von der klassischen Enterprise Architektur hin zur “modernen” verteilten Architektur mit Micro Services. Auf dem Weg vom klassischen Monolithen zu über Messages kommunizierende Micro Services wird es schnell klar, dass hierzu Broker wie Apache Kafka benötigt werden.

Nach dieser Einführung beschrieb Guido die grundlegende Architektur von Kafka. Die Nutzung von Topics und das dahinter stehende publish subscribe wurden dabei ebenso angesprochen wie die Partitionierung eines Topics im Kafka Cluster. Interessant auch die verschiedenen Strategien zum Löschen von über Kafka verteilten Informationen.

Der Vortrag endete mit einem Einblick in das Kafka Ökosystem mit seinen verschiedenen Connectoren. Es wurde aber auch die neue Entwicklung Kafka Streams kurz erwähnt.

SOLID mit Java 8

Die SOLID Prinzipien sind sicherlich jedem bekannt. Sie wurden von Robert C. Martin für die Entwicklung stabiler Software definiert. Roland Mast nahm sich jede der fünf Prinzipien an und stellte dar, wie die Prinzipien mit Java 8 genutzt bzw. umgesetzt wurden.

Single Responsibility lässt sich am besten mit den Lambda Ausdrücken von Java 8 realisieren. Lambdas in Streams kapseln dabei die Verantwortlichkeiten “Streamverarbeitung” und “Bearbeitung der Entities”. Das Open Closed Principle wird sehr schön durch die Default Implementierung im Collection Interface implementiert. Das Interface wird um die Methode forEach erweitert ohne die bereits bestehenden Klassen ändern zu müssen. Für das Liskov’s Substitution Principle stellt Roland die “Umwandlung” von IOExceptions in Unchecked Exceptions vor. Das Interface Segregation Principle findet bei der Nutzung von Functional Interfaces Anwendung. So implementiert die neue LocalTime Klasse fünf Interfaces mit verschiedenen Aspekten der Zeitbearbeitung. Schlussendlich fehlt noch das Dependency Inversion Principle. Hier wird auf das Tool jdeps -jdkinternals hingewiesen. Mit ihm lässt sich erkennen, welche internen nicht zu nutzenden Klassen in einem Java Programm verwendet werden.

StreamProcessing Plattformen und die Qual der Wahl

Zum Abschluss gab es für mich noch einen Vortrag zum Thema Big Data. Nach dem Vergleich von Apache Spark mit Apache Flink stellt Matthias Niehoff weitere Frameworks vor. Er konzentrierte sich aber rein auf die Verarbeitung von Streams.

Zu Begin erläuterte er das Thema des Stream Processing etwas genauer. Die Daten werden hierbei beim Eintreffen sofort verarbeitet. Es findet keine Speicherung und nachgeschaltete Verarbeitung statt. Die Rohdaten werden aber häufig für eine weitere, nachgelagerte Verarbeitung aufgehoben. Das distributed stream processing stellt sicher, dass die Daten kontinuierlich verarbeitet werden. Durch die Verarbeitung in-memory werden sehr geringe Latenzzeiten erreicht.

Problematisch ist die Unterscheidung zwischen Event Time und Processing Time. Die meisten Frameworks arbeiten nur mit der Processing Time. Hierbei wird die Zeit für das Datum verwendet, zu dem es bei der Plattform eingetroffen ist. Im Unterschied hierzu nutzen Frameworks die Event Time wenn die die tatsächliche Zeit des Ereignisses genutzt wird.

Ein weiteres interessantes Feld ist die Art und Weise wie das Windowing durchgeführt wird. In diesem Zusammenhang muss ein State verwaltet werden. Auch hierzu gibt es unterschiedliche Ansätze wie Tumbling, Sliding oder Session. Besonders Problematisch wird die Definition des States, wenn man die Zeit (Event oder Processing) mit ins Spiel bringt.

Im Anschluss vergleicht Matthias die Kandidaten:

• Apache Storm

• Apache Spark

• Apache Samza

• Apache Flink

basierend auf den Grundlagen.

Man kann die Frameworks grob in Stream und Micro Batches orientierte unterscheiden. Auch kann man aufgrund der API in komponentenbasierte und deklarative aufteilen.

Matthias empfiehlt klar deklarative Plattformen. Weiterhin sollte man seiner Meinung nach die hinter einer Plattform stehende Community nicht unterschätzen.

Fazit

Ich bin mit dem Besuch des Java Forum Stuttgart sehr zufrieden. Die von mir besuchten Vorträge haben meine Erwartungen erfüllt. Ich konnte neue Informationen mit nehmen und wurde bei bestehenden Themen bestätigt.

Die Veranstaltung fand in einer angenehmen Atmosphäre statt. Trotz der großen Anzahl an Besuchern wirkte das Veranstaltungszentrum nicht überfüllt. Man merkt den Veranstaltern die langjährige Erfahrung bei der Organisation an.

Ich komme wieder.