"Bean Validation ist sehr nützlich für Microservice-Architekturen"

Inhaltsverzeichnis

Es gibt viele interessante Menschen in der Java-Community, die mit ihrem Engagement in Java Specification Requests (JSRs) und Open-Source-Projekten die Entwicklung vorantreiben. Einige von ihnen möchte ich hier nach und nach vorstellen und mit ihnen über ihre Projekte sprechen. Dieses Mal habe ich mit Gunnar Morling über den vor kurzem angekündigten JSR 380 – Bean Validation 2.0 – gesprochen.

Thorben Janssen: Hallo, Gunnar, erzähle uns doch ein bisschen über dich. Wie bist du zur Softwareentwicklung gekommen, und was machst du heute?

Gunnar Morling: Meine ersten Programmiererfahrungen sammelte ich unter Windows 3.11 mit Turbo Pascal. Nach meinem Studium der Medieninformatik und Stationen unter anderem im Onlinehandel bin ich nun für Red Hat tätig, wo ich an diversen Projekten im Hibernate-Kontext arbeite. In einer internationalen Gemeinschaft aus Kollegen und Community-Mitgliedern Open-Source-Software zu entwickeln, ist jeden Tag aufs Neue sehr spannend und abwechslungsreich.

Janssen: Was machst du privat, wenn du nicht gerade in der Java-Welt unterwegs bist?

Morling: Als Ausgleich zur Arbeit am Computer bin ich gern an der frischen Luft, etwa bei einer Runde Golf mit Freunden. Für kalte Tage habe ich im letzten Winter Basteleien mit Arduino für mich entdeckt.

Neuer JSR zu Bean Validation 2.0

Janssen: Du bist der Specification Lead für den JSR 380 – Bean Validation 2.0. Bevor wir über die geplante Änderungen sprechen, kannst du uns bitte eine kurze Einführung in Bean Validation geben. Was ist das Ziel der Spezifikation, und wo wird sie eingesetzt?

Morling: Bean Validation definiert eine API und ein Metamodell zur Validierung von Java-Objekten. Constraints werden dabei mittels Annotationen wie @NotNull, @Min(10) oder @Pattern(regexp=”[a-z]*”) ausgedrückt.

Zum einen kann man die Validierung per API selbst anstoßen, zum anderen ist Bean Validation aber auch mit vielen anderen Java-Standards wie JPA, JSF oder JAX-RS integriert, die eine automatische Constraint-Prüfung durchführen, wenn etwa eine Entität in der Datenbank persistiert, eine Formularmaske abgeschickt oder ein REST-Request verarbeitet wird. Falls die vordefinierten Constraints für die eigenen Anforderungen nicht genügen, lassen sich eigene, projektspezifische Constraint-Annotationen und -validatoren definieren.

Seit Bean Validation 1.1 gibt es daneben die Validierung von Methodenparametern und -ergebnissen. In Verbindung mit einem Container wie CDI oder dem Spring Framework erlaubt das eine automatische Überprüfung von Parameter- und Rückgabewerten beim Aufruf entsprechend annotierter Methoden. Bean Validation ist Teil von Java EE, lässt sich aber auch unter Java SE problemlos verwenden, zum Beispiel zur Eingabevalidierung in Rich Clients.

Janssen: Welche Änderungen soll die Version 2.0 bringen, und warum wurde der JSR erst so spät gestartet?

Morling: Schwerpunkt von Bean Validation 2.0 wird die Verwendung diverser neuer Sprachfeatures von Java 8 sein:

• Nutzung der neu eingeführten Typannotationen zur Validierung der Elemente von Kollektionstypen wie List oder Set; zum Beispiel lässt sich per List<@Email String> emails ausdrücken, dass jedes Element einer Liste eine gültige E-Mail-Adresse sein soll
• Unterstützung von java.util.Optional und der neuen Date/Time-Datentypen aus JSR 310
  
• einfachere Deklaration etwa mehrerer @Pattern-Constraints für eine Property via @Repeatable[
  
• aussagekräftigere Fehlermeldungen für die Methodenvalidierung mittels der neuen Reflection-API für Parameternamen
  
• eventuell die Nutzung von Lambda-Ausdrücken für sehr kompakte Inline-Constraints

Neben dem Upgrade auf Java 8 planen wir aber auch, andere Feature-Wünsche der Nutzer anzugehen. Das betrifft beispielsweise die Ordnung von Constraints an einzelnen Properties (bisher sind hierzu die sogenannten Validierungsgruppen erforderlich) oder eine API zur Validierung geänderter Property-Werte, bevor diese in ein Modell geschrieben werden. Auch die Integration mit anderen Technologien und Standards wie JSR 354 ("Currency and Money") oder JavaFX stehen auf der Agenda. Daneben verfolgen wir die aktuellen Arbeiten an Java 9 und dem neuen Java-Modulsystem, um Bean Validation gegebenenfalls darauf vorzubereiten.

Bei all dem orientieren wir uns stark an den Erfahrungen und Anforderungen der Community. Das heißt, Vorschläge für Neuerungen und Praxisfeedback zu eventuellen Verbesserungsmöglichkeiten in der API sind uns sehr willkommen.

Zum zweiten Teil der Frage: Nach der Fertigstellung von Bean Validation 1.1 wollten wir der Community zunächst erst mal Zeit geben, die damaligen Neuerungen zu erproben und entsprechende Erfahrungen im Praxisalltag zu sammeln. Auch war es von Beginn an unsere Idee, einen eher kompakten Zeitplan mit einer überschaubaren Menge von Änderungen zu verfolgen, statt über mehrere Jahre an der neuen Version zu arbeiten.

Wie passt Bean Validation 2.0 zu Java EE 8 und MicroProfiles?

Janssen: Oracle schien für einige Zeit das Interesse an Java EE verloren zu haben. Vor kurzem wurde das Interesse an einer Weiterentwicklung aber wieder bekräftigt und auf der JavaOne sollen genauere Pläne bekannt geben werden. Wie siehst du die Zukunft von Java EE, und welche Rolle nimmt dabei die Bean-Validation-Spezifikation ein?

Morling: Ich habe die jüngsten Entwicklungen mit großem Interesse zur Kenntnis genommen und bin auf die Ankündigungen im Rahmen der JavaOne schon sehr gespannt.

Die Idee einer standardisierten Plattform für Enterprise-Applikationen hat für mich nicht an Attraktivität verloren, und ich denke, Java EE kann auch in Zukunft diese Plattform sein, wenn alle Beteiligten eng zusammenarbeiten, die Interessen der Nutzer-Community ernstnehmen und Lösungen für Fragestellungen rund um Entwicklungen wie Cloud-Deployments oder Microservice-Architekturen finden.

Dabei sollte man aber auch nicht vergessen, dass sehr viele Unternehmen nicht die Mengengerüste und Skalierungsanforderungen wie Google oder Facebook haben und oft auch weiterhin mit bewährten Prinzipien wie Transaktionalität oder einfachen Request-/Response-Patterns sehr gut bedient sein werden.

Bean Validation 2.0 soll Teil von Java EE 8 sein und weiterhin die Lösung der Wahl zur Eingabe- und Objektvalidierung in allen Anwendungsschichten sein. Die enge Integration mit anderen Technologien des Java-EE-Stacks soll dabei zu dessen Attraktivität und einer einheitlichen "Developer Experience" beitragen.

Janssen: Eine andere interessante Entwicklung ist die MicroProfile-Initiative, in der Anbieter verschiedener Application Server eine gemeinsame Basis für Microservices schaffen wollen. Bean Validation soll nicht im MicroProfile 1.0 enthalten sein, wird aber als möglicher Bestandteil in späteren Versionen gehandelt. Was ist deine Meinung zur Verwendung von Bean Validation in einer Microservice-Architektur? Und wie siehst du die Chancen, dass die Bean-Validation-Spezifikation in Zukunft zum MicroProfile gehört?

Morling: Ich denke, Bean Validation ist sehr nützlich für Microservice-Architekturen, etwa zur Validierung von REST-Requests zwischen verschiedenen Services.

Verschiedene Microservices können sehr unterschiedliche technologische Anforderungen haben. Daher wäre es in meinen Augen wünschenswert, eine Microservices-Plattform wie MicroProfile wie eine Toolbox mit verschiedenen – per CDI verzahnten – Technologien zu gestalten, aus denen Entwickler gemäß der jeweiligen Anforderungen die erforderlichen aussuchen können.

Die Aufnahme von Bean Validation in eine künftige MicroProfile-Version würde ich dabei natürlich sehr begrüßen. Bis dahin können wir aber zunächst einmal Erfahrungen damit sammeln, wie Entwickler MicroProfile einsetzen, und natürlich werden wir daran arbeiten, dass Bean Validation und die Referenzimplementierung auch schon mit dem MicroProfile 1.0 sehr gut zusammenarbeiten.

Janssen: Wo kann man mehr zum Thema Bean Validation erfahren, und welche Möglichkeiten gibt es, sich an der Weiterentwicklung zu beteiligen?

Morling: Zentraler Anlaufpunkt ist unsere erst kürzlich neu gestaltete Homepage beanvalidation.org. Dort gibt es alle Informationen zu vergangenen und der in Arbeit befindlichen Revision der Spezifikation.

Die Möglichkeiten zur Mitarbeit sind vielfältig. Feedback und Anregungen sind auf unserer Mailingliste herzlich willkommen. Red Hat lebt und atmet den Open-Source-Gedanken, Bean Validation ist da natürlich keine Ausnahme. Dementsprechend sind die Quellen von API, Spezifikation, TCK (Test Compatibility Kit) und der Referenzimplementierung Hibernate Validator auf GitHub frei verfügbar, Pull Requests sind immer gern gesehen. Außerdem kann man Mitglied der Expert Group für JSR 380 werden, die Einzelheiten sind auf der JSR-Homepage zu finden.

Was noch?

Janssen: Welche weiteren Projekte verfolgst du?

Morling: Innerhalb des Hibernate-Teams bei Red Hat arbeite ich neben Bean Validation und Hibernate Validator unter anderem an Hibernate Search (ermöglicht die einfache Implementierung von Volltextsuchen für Domänenmodelle per Lucene/Elasticsearch) und Hibernate OGM (erlaubt die Persistierung von JPA-Entitäten in NoSQL-Stores wie MongoDB, Neo4j oder Infinispan).

Daneben arbeite ich in meiner Freizeit an MapStruct, einem Sourcecode-Generator für Bean-zu-Bean-Mappings, wie sie etwa bei der Abbildung eines internen Objektmodells auf ein externes vorkommen. Ausgehend von einer kleinen Idee zu einem "Nebenbeiprojekt" hat sich in den vergangenen Jahren eine aktive Community aus Nutzern und Entwicklern rund um MapStruct entwickelt, auf die ich sehr stolz bin.

Janssen: Wo kann man dich finden?

Morling: Ich twittere als @gunnarmorling, daneben blogge ich unter in.relation.to/gunnar-morling und gunnarmorling.de.

Janssen: Vielen Dank für das Interview und weiterhin viel Erfolg mit dem JSR 380 und deinen weiteren Projekten. ()