DOAG Deutsche ORACLE-Anwendergruppe e.V.
|  
   

Interview mit Adam Bien: „Es ist noch nichts gestoppt“

Adam Bien arbeitet als „Expert Group“-Mitglied am „Java Community Process“ (JCP) mit und beschäftigt sich seit den frühen Tagen des JDK 1.0 und Servlets/EJB 1.0 mit Java-Technologien. Im Interview spricht der „Java Champion“ und mehrfache Buchautor über seine Einschätzungen und Eindrücke von der JavaOne 2016.

Adam, wie wird sich Java EE deiner Meinung nach verändern?

Java EE übertrifft bereits jetzt die Erwartungen vieler Neueinsteiger. Die Produktivität ist unschlagbar. Allerdings hat man in Java EE 7 zu viele Möglichkeiten, gängige Anforderungen zu lösen. Beispielsweise ist es nicht offensichtlich, dass man mit nur wenigen Zeilen Code die Konfiguration einer Anwendung externalisieren und einen „Circuit Breakr“ implementieren kann, oder dass die Injektion eines ManagedExecutorService die Tür zur Reaktivität bzw. dem Bulkhead öffnet.

Java EE 8 und Java EE 9 werden die Richtung direkter aufzeigen. Die neuen Specs lassen Java EE zu einem mehr und mehr "opinionated" Framework wachsen. In meinen Projekten werden wir auf die restlichen Bibliotheken wie zum Beispiel Breakr oder Porcupine verzichten können. Es sind nur wenige Kilobytes – diese widersprechen jedoch dem minimalistischen Java-EE-Ansatz.

Wie ist deine Meinung dazu, dass Oracle die JSRs MVC, Messaging und Management API gestoppt hat?

Es ist noch nichts gestoppt. Man kann noch ziemlich viel mit der Java EE Community Umfrage erreichen. Ich empfinde das Fehlen von „Concurrency Utilities“ auf den JavaOne-Slides als durchaus kritischer.

Das Fehlen von MVC lässt sich nur schwer erklären. Die Spec und die Referenzimplementierung waren schon sehr weit. MVC wäre eine gute Ergänzung zu den HTML-5-Frameworks. MVC lässt sich gut mit allen gängigen JavaScript-Frameworks kombinieren.

Aber auch EJBs – das aktuell schnellste Komponentenframework – ließe sich mit wenigen Annotationen noch weiter verbessern.

Hältst du es für sinnvoll bzw. realistisch, dass eine oder mehrere von diesen Spezifikationen – innerhalb oder außerhalb des JCP – weiterverfolgt werden?

Davon gehe ich aus. Ich glaube, dass Oracle schon auf die Community hört. Letztendlich besteht die Community aus Entwicklern, die mehr und mehr in die Technologieentscheidungen großer Firmen involviert werden.

Aus diesem Grund sollten alle Leser des Interviews an der Umfrage teilnehmen und auch die Wichtigkeit von „Concurrency Utilities“ von Java EE (zum Beispiel injizierbare Thread Pools) erwähnen. Ich habe die Umfrage zwischen den JavaOne Sessions ausgefüllt – es dauert weniger als fünf Minuten.

Was sagst du zu den neuen vorgeschlagenen JSRs „Health Checking“ und „Configuration“?

Health Checking ist essentiell wichtig. Ich hatte schon mehrfach versucht, eine solche Spec voranzutreiben. Die Veröffentlichung von Monitoring-Daten über leichtzugängliche Protokolle wie zum Beispiel HTTP und REST ist nicht nur beim Testen hilfreich, sondern auch eine wichtige Voraussetzung beim Betrieb in elastischen Umgebungen.

In der Configuration wird bereits das Apache-Tamaya-Framework berücksichtigt – mit vielen frischen Ideen. Hierbei sollte man sich insbesondere auf die Integration mit bestehenden Specs konzentrieren. Die Integration der Configuration API mit der JPA und persistence.xml oder Servlets mit web.xml oder auch mit der JDBC-Konfiguration der Server würde beispielsweise das Deployment in "Staged Environments" eleganter lösen.

Oracle hat in einem Vortrag auf der JavaOne CQRS im Gegensatz zu CRUD-Services propagiert. Wie ist deine Meinung herzu?

Wenn man das "C", "R", "U" und "D" auf verschiedene Java-Klassen verteilt, erhält man automatisch das CQRS. In vielen Projekten wird CQRS bereits eingesetzt, ohne eine bewusste Wahrnehmung dieses Patterns.

Besonders in hoch skalierbaren Umgebungen bringt das CQRS Vorteile, da man aus einer DataSource liest und in eine schreibt. Beide Datenquellen werden im Hintergrund asynchron repliziert, was sich positiv auf die Skalierbarkeit und negativ auf die Konsistenz auswirkt. Dieses Verhalten ist nicht für alle Projekte sinnvoll.

In Zukunft wird es bestimmt noch Architekturen geben, bei denen man auf Microservices und Cloud-Ansatz verzichten möchte. Denkst du, dass dies weiterhin ohne Probleme möglich sein wird? Anders formuliert: Wird der “klassische” Ansatz ein “First Class Citizen” bleiben?

Die Hardware wird immer günstiger. Ich glaube, dass es bald einen Trend zurück zu "On Prem" geben sollte. Eigene Server mit "Cloud Management Software" werden immer attraktiver und kostengünstiger. Die Hardware wird nicht nur leistungsfähiger, sondern auch noch effizienter. Die neuen Server verbrauchen weniger Strom als die Vorgängergeneration. Strom ist einer der Hauptkosten.

Auf Microservices versuche ich immer zuerst zu verzichten. Viele meiner Projekte bestehen aus einem kleinen WAR, gebaut von genau einem Team mit wenigen externen Abhängigkeiten, deployed auf genau einen Applikationsserver (siehe „Why not one application per server/domain?“). Das ist immer noch die perfekte Java-EE-Architektur – auch bekannt unter dem Begriff "Monolith".
Neue Anforderungen, zusätzliche Teams etc. resultieren oft aus weiteren WARs. So entstehen Microservices in Java EE. Es ist ein Bottom-Up- und kein Top-Down-Ansatz.

Was rätst du der Community jetzt nach der JavaOne – welche Dinge sollte sie inhaltlich und im Verhältnis zu Oracle „anpacken“?

Zuerst unbedingt an der