• 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.

• 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.

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).

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.

• 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.

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.

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.

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

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