JSR-303 Bean Validation
|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 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: |
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: |
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.
|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 email@example.com. |
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.|