InfoQ

News

Initial Draft of the Bean Validation Specification Released

Posted by Charles Humble on Apr 09, 2008 02:33 PM

Community
Java
Topics
JCP Standards
Tags
Validation
In most enterprise applications data constraints will exist in two places:
1. In the model (typically as database schema constraints).
2. In the application code.
Both are important. Database constraints allow reuse of the underlying data model in the event that the application code needs to be migrated. Application level validation is able to provide finer grained control (is this a valid email address? is the customer's date of birth in the future?) than can be easily achieved with model level constraints, and can also more readily provide meaningful error messages to the users of the application. Application level validation may in itself reside in multiple places, resulting in a large amount of duplication of effort across the different application tiers. In a typical web application, for example, JavaScript is executed in the browser for simple field level validations and the serverside layer is used for more complex business rule validations. It would be highly desirable to be able to centralize the validation definitions in one place and share the definitions across the different layers.

Led by Hibernate Validator lead developer Emmanuel Bernard, JSR-303 aims to standardize the constraints metadata model for Java EE 6. An early draft of the specification has been released and the expert group are keen to solicit feedback. As part of this a forum has been set up, and Bernard has begun to publish a series of articles (part 1, part 2) on the Hibernate blog describing how the API works.

Unsurprisingly given its parentage, JSR-303 is heavily influenced by the JBoss' Hibernate Validations although a number of the other validator frameworks (Xwork and the Apache Commons Validator for instance) have also influenced the specification. It uses annotations for the majority of cases and provides standard APIs for runtime validation and to query the metadata. Each constraint annotation must define a message of type String which is used to create an error message. Error messages support internationalisation. Constraints may be declared on an object's fields, getters, class, superclass and interfaces and validating an object will validate all of its constraints. For example the following code creates a String called street1 which has a maximum length of fifty characters and is mandatory:

@NotEmpty @Max(50)
private String street1;

The framework is designed to be extensible so that an application can easily define its own additional set of constraints. From the first blog entry:

"A constraint is comprised of:
• an annotation
• a constraint validation implementation
While the annotation expresses the constraint on the domain model, the validation implementation decides whether a given value passes the constraint or not."

As well as supporting instance validation the specification supports validation of an object graph, so for example if a bean ClientDetails contains an Address bean with one or more @Valid annotations the validator will validate the contents of the Address bean when the ClientDetails bean is validated.

One significant difference between the spec and the Hibernate Validator is the concept of groups, which provide a means for creating subsets of validations. Groups have an associated sequence (set via an @GroupSequence annotation) so that a developer can force one set of constraints to pass without error before the next set executes. Groups also allow a partial validation of the JavaBean. The draft specification suggests two scenarios where this might be useful:

"• the second group depends on a stable state to run properly
• the second group is a heavy consumer of time, CPU or memory and should be avoided if possible"
A number of different pieces of technology in the Java EE 6 platform should be able to take advantage of JSR-303. For example DDL updates when generated via an ORM tool, entity validation on insertion/update by the Java Persistence API, the new WebBeans API, and JavaServerFaces components all look to be obvious candidates.

3 comments

Reply

Blog entry on groups by Emmanuel Bernard Posted Apr 10, 2008 2:29 PM
XML Forms support? by Martin Probst Posted Apr 11, 2008 12:30 AM
Re: XML Forms support? by Emmanuel Bernard Posted Apr 11, 2008 9:58 AM
  1. Back to top

    Blog entry on groups

    Apr 10, 2008 2:29 PM by Emmanuel Bernard

    I have just written a blog entry on groups here.
    Emmanuel Bernard

  2. Back to top

    XML Forms support?

    Apr 11, 2008 12:30 AM by Martin Probst

    It would be highly interesting if there was an implementation that could automatically map from JSR-303 metadata to other validation schemes, e.g. XML Forms types, client side JavaScript etc. Anything like that?

  3. Back to top

    Re: XML Forms support?

    Apr 11, 2008 9:58 AM by Emmanuel Bernard

    The spec is written in such a way and exposes metadata APIs so that your client side JS library, your XML Forms type consumer and so on can go and extract the info from the domain model. The next step is to talk to the JPA 2 and JSF 2 expert groups to match this integration in the respective specifications. Specific converters are not part of the spec because as you pointed out there are gazillions of validation schemes :)

Exclusive Content

VMware Infrastructure 3 Book Excerpt and Author Interview

VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.

Architectures of extraordinarily large, self-sustaining systems

Can a system that is so large it cannot be comprehended be "designed" in a conventional sense? The foundations of computing are about to change. In this talk, Richard P. Gabriel explores why and how.

Using Ruby Fibers for Async I/O: NeverBlock and Revactor

Ruby 1.9's Fibers and non-blocking I/O are getting more attention - we talked to Mohammad A. Ali of the NeverBlock project and Tony Arcieri of the Revactor project.

Agile and Beyond - The Power of Aspirational Teams

Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away.

Concurrency: Past and Present

Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.

ActionScript 3 for Java Programmers

Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.

Neal Ford On Programming Languages and Platforms

Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.

Future Directions for Agile

David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.