Today I've got some great news to share with you: a new revision of the Bean Validation spec is about to be kicked off!
Over the last weeks, we've been busy with preparing a proposal for this JSR and I've submitted it to the JCP (Java Community Process) last week. You can find the proposal for "JSR 380: Bean Validation 2.0" on jcp.org.
In the following, let's take a look at what we think should be part of Bean Validation 2.0 and what we've planned as the next steps.
Bean Validation 1.0 and 1.1 (JSRs 303/349) saw a huge adoption by the Java community and are integrated with a wide range of technologies, be it other Java standards (e.g. CDI, JPA, JAX-RS) or 3rd party libraries and frameworks such as Spring, Vaadin and many, many more.
The main contribution of Bean Validation 1.1 - the declarative validation of method-level constraints - has been integrated into techs such as CDI and Spring, making it a breeze to write expressive API contracts with constraints which are automatically validated upon execution.
Bean Validation 1.1 has been finalized three years ago and Java continued to evolve since then. Java 8 - released in 2014 - brings many very interesting language features to the table, but also adds a new time and date API and much more.
So it's about time that Bean Validation supports new JDK types such as
Optional, but also takes advantage of new (language) features such as type annotations, repeatable annotations, reflective parameter name retrieval, lambda expressions etc.
To give just one example, let's consider the requirement of applying constraints to the elements of a specific collection. This has been a long-standing feature request, but we could never find a way to solve it generically in an acceptable manner.
Java 8 finally provides the perfect tool to solve this issue: type annotations. Annotating type parameters of collections is a very intuitive way to apply constraints to collection elements (and not the entire collection itself):
List<@Email String> emails;
Java 8 provides the required APIs to retrieve the constraint annotation from the type parameter and apply the validation accordingly.
But it doesn't stop there. Repeatable annotation types will make it less verbose to specify several constraints of the same type one and the same element. Reflective parameter name retrieval will provide better validation messages out of the box when validating constraints on method parameters. Lambda expressions might be a useful vehicle to express small ad-hoc validation routines.
While we envision supporting and leveraging Java 8 as the "main theme" of Bean Validation 2.0, we hope to address some other issues, too. E.g. there may be support for more customized payloads of constraint violations. Also a builder API for constraint violation exceptions might be useful. As would an API for validating an object graph assuming a list of changes to be applied. Check out the JSR 380 proposal for some more ideas we have.
While the baseline for Bean Validation 2.0 will be Java 8, we'll also be tracking the ongoing work for Java 9 and work towards making Bean Validation ready for Java 9 and its module system as far as possible.
As the time-line of Bean Validation 2.0 is quite compact, we are very eager to hear from you, the community of users, and learn what would be the things most useful to you. For sure we won't be able to address all potential ideas out there. So if there are features close to your heart which you'd really love to see in the spec, be sure to speak up and let us know.
As per the rules of the Java Community Process, the Bean Validation 2.0 JSR is currently up for review by the JCP executive committee. After that, there will be an approval ballot and we will hopefully be ready to go and kick off the work on actual spec changes, prototyping new features in the reference implementation and so on.
So if you ever wanted to contribute to a Java Specification Request - be it just by voting for issues, opening new feature requests or actually working on the specification, its reference implementation and the test compatability kit (TCK) - then this is the perfect time. If you are a member of the JCP, you also can join the expert group, we'd be very happy to have you aboard.
Whether EG member or not, in order to get the discussion on this JSR proposal started, just drop a comment below, post to the feedback forum, shoot a message to the Bean Validation mailing list or comment on specific issues in the tracker.
We are looking forward to hearing from you and get Bean Validation 2.0 rolling!
Exactly one year after the last maintenance release we've published version 1.1.4.Final of the Bean Validation TCK today. It contains exactly one issue, BVTCK-68, which is about the removal of two tests from the TCK which could not be tested in a portable manner across containers. Check out the issue itself for the complete story.
As always, the new TCK version is available for download as TAR.GZ and ZIP on SourceForge. Alternatively you can obtain the test suite via Maven, Gradle etc. using the coordinates org.hibernate.beanvalidation.tck:beanvalidation-tck-tests:1.1.4.Final.
More information about the Bean Validation TCK can be found here and the TCK reference guide. In case you have any questions or ideas around the Bean Validation specification in general or the TCK in particular, don't hesitate to contact us through our mailing list.
Good news for those of you who want to certify the compatibility of a Bean Validation implementation (and its API JAR) against Java SE 8.
We have released updates to the Bean Validation TCK 1.0 and 1.1; The versions are 1.0.7.GA and 1.1.3.Final, respectively. Both TCK releases come now with a version of the API signature file which works with Java SE 8. This signature file can be used to assert API compatibility with JSR 303/349 via the SigTest tool. SigTest 3.0 needs to be used from now on. Note that the actual tests of the TCKs remain unchanged.
Don't hesitate to contact us in case you have any questions around the Bean Validation specification in general or the TCK in particular.
I have two good Bean Validation related content for you today.
Training slides (in French)
Laurent Guerin wrote a comprehensive training on Bean Validation (1.0 and 1.1) for French students. The slides are available under a Creative Commons license. I did review them and they are very good.
The bad news is that they are in French. The good news is that they are in French!
Video training (in English)
Antonio Goncalves, my esteemed co-host of Les Cast Codeurs has published a 2 and a half hour video training on Bean Validation. It is hosted on Pluralsight where packages start at $29 / month but you can get the first 10 days free.
The good news is that Antonio has a Dr Love / French accent combo voice. The bad news? I'll let you find out ;)
Let me know if you have found good materials on Bean Validation. We might start a dedicated page on the website.
Antonio Goncalves, fellow JCP member and friend has asked me why Bean Validation XML's namespace has not moved from its original location to the jcp.org location like other Java EE 7 specifications.
I don't remember being aware that such a move was orchestrated so there are two possible reasons:
- I was never been made aware of the move,
- I was aware of it but considered that it was low priority compared to the other issues we were working on.
Provided we had to work hard till the last minute, and that the community never was keen on the XML support we put in Bean Validation, #2 is not impossible but I suspect it's #1 or I would have opened an issue to track the task.
Anyways, that's not a problem. Anyone can open an issue (I've just created one for this task), write a couple of pull requests to fix the spec, TCK and RI as explained in our contribute section. Scratch your own itch: so who's jumping? :)
We will have to wait for the next version of the spec to avoid breaking older applications but if it's committed, it won't be forgotten.
PS: no, I'm not bitter, but since I haven't blogged in a while that was a good occasion to remind everyone of the power of contributions ;)
Stay up to date, subscribe to the news feed.