Kolumne: EnterpriseTales

Einer für alle – alle für einen: Bean Validation 1.1

Lars Röwekamp und Matthias Weßendorf

Es gibt wohl kaum eine andere Java-Spezifikation, die so eng mit der Community verbunden ist wie das Bean-Validation-API. Erwachsen aus einem Open-Source-Projekt, sind auch weiterhin die Anforderungen und Wünsche der Anwender maßgeblicher Treiber für Neuerungen und Verbesserungen. Wie die kommende Version in etwa aussehen könnte, zeigt ein Blick in die Kristallkugel aka JSR 349 Early Draft.

Das Bean-Validation-API ist deutlich mehr als nur eine Spezifikation inklusive Referenzimplementierung. Ein Blick auf die zugehörige Webseite [1] macht klar, wie auch in einen offiziellen JSR die Community gewinnbringend mit eingebunden werden kann und so der ursprüngliche Open-Source-Gedanke erhalten bleibt. So wundert es auch nicht, dass ein Großteil der bisher für die aktuell als Early Draft vorliegende Version 1.1 [2] angedachten Neuerungen und Erweiterungen das direkte Feedback der Nutzergemeinde darstellt. Bevor wir das eine oder andere zukünftige Feature im Detail anschauen, soll kurz ein Überblick über die wichtigsten zu erwartenden Neuerungen gegeben werden:

  • Integration mit weiteren APIs: bessere Integration in weitere JSRs wie JAX-RS, JAXB, EJB sowie JPA und CDI
  • Method-Level Validation: Validierung von Methodenparametern und -rückgabewerten
  • Dependency Injection: CDI-Support für Bean Validation Components (MessageInterpolator, ConstraintValidatorFactory und ConstraintValidator)
  • Constraint Composition: Erweiterung der Komposition von bestehenden Constraints durch OR-Verknüpfungen. Aktuell sind Kompositionen automatisch AND-Verknüpfungen.
  • Group Propagation: Überführung einer Constraint-Gruppe in eine andere Gruppe bei kaskadierenden Validierungen
  • Constraints für Collection-Elemente: Aktuell werden lediglich Constraints auf einer Collection selbst oder kaskadierende Constraints auf den enthaltenen Elementen unterstützt. Zukünftig soll auch die direkte Angabe von Constraints auf Collection-Element-Ebene möglich sein, wodurch zum Beispiel die Validierung von nativen Typen unterstützt werden wird. Dies ist eigentlich nur ein Workaround für die nach wie vor fehlende Unterstützung von Annotationen auf Java-Typen (JSR 308 – Early Draft).
Integration

Wenn auch nicht offizieller Bestandteil des Bean-Validation-API, legt die Spezifikation großen Wert darauf, sich optimal in die verschiedenen Lifecycles der Java-SE/EE-Plattformen einzubetten. Ein gutes Beispiel hierfür ist die bereits heute schon bestehende Integration in JSF 2 und JPA 2. Angedacht für die Version 1.1 ist insbesondere eine zusätzliche Integration in JAX-RS zur besseren Validierung von WebService-Parametern und Return-Werten, sowie eine Integration in JAXB zur Konvertierung von BeanValidation Annotation in XML-Schema-Deskriptoren (vice versa).

Aber auch bereits vorhandene Integrationen sollen verbessert werden. Innerhalb von JPA soll zukünftig die Generierung von DDL-Fragmenten mittels Bean Validation Constraints am Entity-Modell gesteuert werden können. EJB und CDI werden neben der aktuell vorhandenen Property-Level-Validation zukünftig auch Method-Level-Validation unterstützen (siehe unten). Ebenfalls in Planung sind JSF Class Level Constraints, mit deren Hilfe clientseitige Validierung auf Basis von Java Constraints ermöglicht werden soll, wie man es heute bereits von einigen Third-Party Libraries her kennt.

Method-Level-Validation

Eine der wohl wesentlichsten und übergreifenden Neuerungen in der Bean-Validation-1.1-Spezifikation stellt die Method-Level-Validation dar. Sie erlaubt zukünftig das Platzieren von Constraints an Methoden- und Konstruktor-Parametern sowie an Methodenückgabewerten.

Das als „Programming by Contract“ (kurz: PbC) bekannte Pattern erlaubt über diesen Weg, Pre- und Post-Conditions für Methodenaufrufe zu deklarieren. Neben dem Vorteil der besseren Lesbarkeit – auch ohne Zusatzdokumentation – werden so redundante Prüfungen im aufrufenden Code obsolet. Potenziell kann Method-Level-Validation auf jeder non-static-Methode angewendet werden. Es ist aber durchaus erlaubt, dass einzelne Spezifikationen zusätzliche Restriktionen – zum Beispiel public und/oder non-final – mit ins Feld führen. Listing 1 zeigt ein einfaches Beispiel für Method-Level-Parameter-Validation aus der Spezifikation.

Listing 1

public class OrderService {

    public OrderService(@NotNull CreditCardProcessor creditCardProcessor) {
        //...
    }

    public void placeOrder(
        @NotNull @Size(min=3, max=20) String customerCode,
        @NotNull Item item,
        @Min(1) int quantity) {
        //...
    }
} 
Geschrieben von
Lars Röwekamp und Matthias Weßendorf
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.