JavaOne 2016

Konferenzen sind der ideale Ort, um aus dem Entwickler-Alltagsgeschäft auszubrechen und wieder mal ein Gefühl dafür zu bekommen, welche Hype-Wellen gerade über das Ökosystem rollen oder gerollt werden. Die diesjährige JavaOne 2016 in San Francisco – das ist die Oracle-Hauskonferenz – machte hier keine Ausnahme und ein Blick auf die Agenda der angebotenen Sessions und Tutorials zeigte deutlich die angesagten Schlüsselworte: Cloud, Microservices, Reactive Programming sowie IoT.

Etwas abseits des Mainstreams hatte ich das Vergnügen, eine Session gestalten zu dürfen: “jQAssistant: Verify Your Design and Architecture“. In dieser lagen die Schwerpunkte einerseits auf der Einführung in Philospohie und Funktionsweise des Werkzeugs, insbesondere aber in der Modellierung von Architekturkonzepten in Codestrukturen bzw. deren Abbildung im Graphen sowie der Formulierung von Regeln in ausführbarer Dokumentation (Asciidoc) für Entwickler. Das unmittelbare Feedback war sehr positiv, insbesondere der letzte Aspekt stieß wiederum auf sehr reges Interesse. Dieser zeigt einen gangbaren Weg auf, die zwar gebräuchlichen, aber naturgemäß stets veralteten Wiki-Seiten bzw. Word-Dokumente abzulösen.

Ich konnte insgesamt nur zwei volle Tage vor Ort sein. Einen Abend davon nutzte ich, um jQAssisant bei der Neo4j-Meetup-Group von San Francisco vorzustellen. Dabei lag der Schwerpunkt auf der Exploration bestehender Anwendungsstrukturen sowie der Gewinnung bzw. Bewertung individueller Metriken.

Leider konnte ich die Keynote der JavaOne mit den sehnsüchtig erwarteten Aussagen zur Zukunft von Java EE nicht besuchen. Das Ergebnis ist mittlerweile bekannt: es gibt ein Commitment zum Standard, Java EE 8 soll Ende 2017 verabschiedet werden und stellt im Wesentlichen eine Auffrischung mit kleineren (Configuration) und ausbleibenden Ergänzungen (MVC) dar. Zwischenzeitlich wird bereits an Java EE 9 gearbeitet, welches – wie die Gerüchteküche es im Vorfeld auch bereits vermutete – eine Neuausrichtung wagt und ein reaktives Programmiermodell anvisiert. Interessant ist dabei der Zeitplan: das Ergebnis soll bereits ein Jahr später verabschiedet werden, was selbst ein Oracle-Mitarbeiter in einem persönlichen Gespräch als zu ambitioniert und unrealistisch einschätzte. Wer den Spezifikationsprozess über die Jahre verfolgt hat, kann diese Auffassung bestätigen. Es ging Oracle offensichtlich erst einmal darum, ein Signal für Java EE zu senden und das sollte trotzdem gelungen sein.

Parallel dazu war deutlich erkennbar, dass man sehr bemüht ist, den Boden für eine hohe Akzeptanz des kommenden Java 9 zu bereiten. Es wurden viele Sessions angeboten, die sich den neuen Features (z. B. JShell) und der wahrscheinlich “heißesten” Änderung widmete: der Modularisierung mit Project Jigsaw und den damit ggf. verbundenen Inkompatibilitäten bei der Migration bestehender Anwendungen. Es wurde auffallend oft (aber zurecht) betont, welchen Stellenwert eine auf Stabilität orientierte Weiterentwicklung hat und dass bisher keine bereitgestellte Funktionalität entfernt wurde. Mit Java 9 wird hier allerdings, wenn auch sehr langsam, ein Paradigmenwechsel eingeleitet: um eine Modularisierung der Plattform zu ermöglichen, wurden 6(!) public-Methoden entfernt. Es wurde deutlich gemacht, dass sich der Prozess des Entsorgens von Altlasten in kommenden Versionen fortsetzen wird. Das wurde insbesondere in einer Fragestunde unter dem Titel “Meet the JDK architects” (mit Mark Reinhold, John Rose und Brian Goetz) sehr deutlich. Diese Session war überhaupt sehr aufschlussreich und unterhaltsam, weil zuweilen mit recht trockener Ironie argumentiert wurde. Getrieben durch Fragen von Entwicklern wurde klar, welche Werte bei der Weiterentwicklung von Plattform und Sprache eine Rolle spielen: Stabilität und ein nachweisbarer Mehrwehrt für neue Features. Die Untersützung von Ahead-Of-Time-Compilation oder Currying wurden unter letzterem Betrachtungswinkel als klar “Low-Priority” deklariert, währenddessen eine Verringerung des Overheads beim Thread-Handling in Aussicht gestellt wurde, um reaktiven Programmiermodellen bzw. entsprechenden Frameworks entgegenzukommen. Die Antwort auf die Frage nach dem “biggest regret” in der Geschichte von Java war übrigens wenig überraschend “Serialization”, verbunden mit der Aussage, dass der aktuelle Mechanismus die mit Abstand meisten Security-Issues verursacht hat…

Im Hinblick auf die Agenda der Konferenz möchte ich abschließend noch auf eine kleine Wahrnehmung am Rande hinweisen: es gab bekanntermaßen vor nicht allzu langer Zeit Spekulationen über eine möglicherweise unsichere Zukunft von JavaFX. Dem entgegen stand aber eine spürbare Menge der JavaOne-Sessions, die sich diesem Thema widmeten. Ähnlich optimistisch fiel dazu auch die Einschätzung in einem Panel zu RIA-Technologien aus, in welcher u. a. auch JavaFX als Basis für Cross-Plattform-Entwicklung im Bereich mobiler Geräte diskutiert wurde.

Slides zu meiner Session:
jQAssistant: Verify Your Design and Architecture (PDF)

Impressionen zur JavaOne 2016 in San Francisco: