What Should go in JSR 303?

Bean Validation 1.1 Spec

Jessica Thornsby

Bean Validation 1.1: “more about an incremental evolution than a revolution.”

Last week, spec lead of JSR 303: Bean Validation, Emmanuel
Bernard, opened the discussion on
what should be included in the Bean Validation 1.1
. JAXenter spoke to Emmanuel Bernard, to find out
more about his proposal for greater collaboration between JSRs
leads, and what else is being considered for inclusion in the

JAXenter: The next release of the Bean
Validation JSR will be a 1.1 release and not a 2.0 release. What
influenced this decision?

Emmanuel Bernard: I would say mainly the warm
welcome Java developers have given the specification. It is always
difficult to do a version 1.0 for a specification:
– you don’t want to add useless features that will haunt you for
ever and ever.
– you do not want to miss critical features which will hamper its

From the feedback we have gathered, Bean Validation 1.0 was
close to the sweet spot. We had demands for both new features and
features we already had in mind but decided to leave out of the
spec for the 1.0 version. These will be the meat of Bean Validation
1.1. This release will be about filling those gaps and is more
about an incremental evolution than a revolution.

That being said, version numbers are a pure marketing tool,
there is nothing in the JCP describing version number usages.

JAXenter: When listing your thoughts on Bean
Validation 1.1, you wrote about encouraging collaboration with
other JSR leads. What are the benefits of a more collaborative
approach to specifications?

Emmanuel: Consistency! It is vital that spec
leads communicate and align each other’s specs to ensure platform
consistency (SE or EE). When developers choose a platform like Java
EE, they do it to avoid all the integration work, they want to feel
it’s a single programmatic model. For Bean Validation, it means
making sure others specifications embrace the Bean Validation
constraint model instead of reinventing their own. In a way,
integration with other specifications is going to be the most
important goal of Bean Validation 1.1.

JAXenter: What new features do you propose for
Bean Validation, in the field of CDI?

Emmanuel: There are two interesting areas. First off, Bean
Validation components (like constraint validators for example)
should be treated as CDI components and support injection.

More interesting I think for developers will be declarative
method validation. We want to offer the ability to validate
parameter values and return values upon method calls. Often a
business service requires well formed and valid parameters to
perform correctly. If that is not the case, some exception should
be raised. Today, you have to explicitly call the Bean Validation
API to validate your parameters. The idea with Bean Validation 1.1
and CDI.next is to provide an annotation driven approach to
transparently trigger parameter validation upon a method call. To
achieve that, Bean Validation will offer low level APIs to do
parameter as well as return value validation while CDI will offer
the appropriate interceptor to declaratively intercept method calls
and execute Bean Validation’s logic.

comments powered by Disqus