Bean Validation 1.1 Spec
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 specification. 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 spec.
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 usefulness.
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.