On 14th November 2007, Emmanuel Bernard from Red Hat/JBoss Division became the new specification lead for JSR-303 Bean Validation. Mark Newton recently caught up with him to find out what this means for Java developers looking to write robust applications. Here's what he had to say.

The Interview

Mark What is the purpose of JSR-303 Bean Validation?

Emmanuel In today's Java applications, data constraints are duplicated across the application code:

 

• the database (through schema constraints)
• the data access layer
• the service or business layer
• the presentation layer
• the client layer (through JavaScript code)

 

The real problem here is not really multiple levels of validations, the problem is that the constraint declarations are duplicated across all these layers leading to inconsistencies and maintenance nightmares. If I want to make a property not null, I need to update my code in potentially 5 different places: a perfect incubation environment for the copy paste virus.

 

The purpose of JSR-303 is to solve these problems.

Mark How does the specification achieve that?

Emmanuel JSR-303 defines:

 

• a common way to declare constraints on JavaBeans (primarily through annotations but also through XML)
• a standard validation API
• a common constraint metadata request API

 

In more concrete terms, a Java developer will be able to add constraint annotations to his domain model (@NotNull, @Email, ...), and use a standard API to validate the domain model objects (or, even better, have his favorite application framework validate them for him). Finally any framework interested in metadata will be able to reuse the declared constraints: tools, presentation frameworks generating JavaScript and so on. The same constraint declarations easily defined on a JavaBean, by annotating its properties once, will then be reusable by any application, any framework, any JSR.

 

The beauty of using annotations comes from the fact that constraints are naturally visible when reading the source code. Constraints really are class metadata, they belong here.

Mark Why should people care about using a standard validation meta-model and API?

Emmanuel Primarily because they are lazy

 

Why would I declare my data constraints several times across several layers and face the risk of inconsistency?

 

Why would I rewrite an email validation routine if someone else has done it already?

 

Why, as a framework developer, would I want to force my user to redefine their data constraints?

 

This specification plays a big role in increasing ease of use and enforcing the DRY (Don't Repeat Yourself) principle not only for a specific platform or layer but across the whole Java ecosystem (SE, EE and even potentially ME).

Mark Is the intention of this specification to solve the issue of validation in Java application development once and for all?

Emmanuel No, the intention is to take over the world but that's a long term vision

 

Anybody that decided to solve a problem once and for all has failed. The Expert Group's intention is to provide a common ground for validations that can be assumed and reused by anybody. The spec defines several extension points for easy integration and extensions. The most important one is to let anybody define custom constraint validations: it's as simple as defining an annotation and a validation routine.

 

Defining a validation framework is always a tradeoff between simplicity, ease of use and flexibility. This is where the expert group spends most of its time at the moment.

Mark How many existing validation frameworks are you looking at from the Java community to form the standard?

Emmanuel We tried to gather as much knowledge and experience as possible. To name a few frameworks we are looking at, whose members are in the expert group:

 

• Apache Commons Validator
• Hibernate Validator
• JSF
• Oracle ADF
• RIFE
• Spring Bean Validation
• Stripes
• XWork Validation

 

This is a lot of experience not only from the OSS community but also from the Java ecosystem in general with Oracle, Sun, Google, and also individuals "regular users" onboard.

Mark How does this JSR fit in with other bean related JSRs at the moment: 273 - Design time API for JavaBeans, 295 - Beans Binding, and 305 - Annotations for Software Defect Detection?

Emmanuel You are actually missing a few others like 316 - Java Persistence 2.0, 299 - Web Beans, 314 - JavaServer Faces 2.0

 

JSR-303 provides two integration key points. A validation API to validate a JavaBean instance and a constraint repository API to read and reuse the constraint metadata information. The various JSRs will be able to use either one of these integration points. Let's take Java Persistence for example: Java Persistence could consume the constraint metadata informations to automatically update the database schema, it could also ensure that any entity instance persisted or updated is valid by calling the runtime validation API.

 

JSR-305 - Annotations for Software defect Detection is a slightly different case but both spec leads are willing to collaborate to make sure similar concepts are at least aligned and at best reused.

Mark It sounds to me like validation may occur multiple times if JSR-303 is used by different application tiers. For example if I enter a value into a web form then it could be validated by JavaScript, a Servlet, an EJB, and then the database. Is this correct and if so doesn't this represent a performance hit?

Emmanuel You are correct, it will be validated multiple times. But you have different tiers that achieve different purposes and they might even be reused (think batch process vs online process).

 

Remember that different application frameworks will most likely be configurable to enable or disable validation, some of them even declaratively on a per tag region or method basis (this is the case in JBoss Seam for example).

 

If I had to focus on 2 tiers, I would choose the presentation and the persistence tiers. The presentation tier is where the user enters data and where you can give very accurate feedback to your user. The persistence tier is where data is about to reach... persistence: nobody wants to manually fix broken data because some smart developer (who has since left) thought it might be a good idea to save 2 milliseconds.

Mark Will Hibernate Validator be made JSR-303 compliant and if so will it be separated from the Hibernate project so that it can be used in different tiers other than the persistence tier?

Emmanuel Hibernate Validator is already separated from Hibernate core and can be used in any Java Persistence compliant provider. It is already usable in different tiers, As a matter of fact JBoss Seam is a big consumer of Hibernate Validator: the validation metadata is reused all the way from the presentation tier (JSF), through the component tier (JBoss Seam, EJB 3.0) to the persistence tier (Hibernate and the database schema).

 

As Hibernate has been made Java Persistence compliant, Hibernate Validator will implement the JSR-303 Bean Validation specification.

Mark What stage are you at in the specification process and how can the community help out?

Emmanuel We hope to release an Early draft in about a month so that the community can give feedback. It will also be interesting to get feedback from other JSRs too. Comments are always welcome and can be addressed to jsr-303-comments@jcp.org.

 

The reference implementation work will start at some point next year too, hands are also welcome

Mark When should we expect a final release?

Emmanuel Depending on the feedback, it could be as fast as the first half of 2008, but a more reasonable timeframe is probably second half of 2008. In the meantime several intermediate drafts will reach the community.

Mark Thanks for taking the time to talk with us.

Emmanuel Thank you!