Jakarta Bean Validation

The work on Bean Validation 2.0 is in full swing and there is an issue where we could benefit from your help.

Recently we have been discussing whether any new constraints should be added to the specification or not. Traditionally, Bean Validation stayed on the conservative side of things in this regard. It defined only some generically applicable and widely useful constraints in the specification itself, e.g. @NotNull, @Size or @Pattern.

Now Marco Molteni did a very interesting analysis on the constraints which are actually used in real world projects by running an analysis of open source projects hosted on GitHub. Only a specific type of project is hosted there usually (mostly libraries, as opposed to actual end user facing applications), so the numbers should be taken with a grain of salt. But nevertheless they are very interesting.

Marco's analysis shows that besides the BV-defined constraints @NotEmpty and @NotBlank - both defined by the reference implementation Hibernate validator - are very frequently used and thus are potential candidates for inclusion into Bean Validation 2.0. The former asserts that the annotated string, collection, map or array is neither null nor empty, the latter validates that the annotated string is neither null nor empty, stripping leading/trailing whitespace.

Another candidate may be @Email; but validation of e-mail addresses is a surprisingly complex business, with different people having different ideas and expectations of how a valid (or invalid) e-mail address should look like (take a look at the examples on Wikipedia to get an idea). Hence I feel this is not something we should aim for in the specification.

To add some further data points, we created the following survey on constraints to be added potentially. Getting back many answers to this poll will help us to form a better understanding of what you, the users out there, really need. If you would like to see support for other constraints not mentioned in the survey, you can add them via the free-text field in the last question. These may be custom constraints defined by a Bean Validation provider, a third-party library or in your own projects which you see yourself using very frequently.

Taking the survey will take you only a minute, so give it a go. Thanks a lot for your help!

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.

Looking back...

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.

...and forward

So it's about time that Bean Validation supports new JDK types such as LocalTime or 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.

What else?

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.

What's next?

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.

You can get distribution bundles with the new signature file from SourceForge (1.0, 1.1).

More information about the Bean Validation TCK can be found here. Refer to the TCK reference guide (1.0, 1.1) if you would like to learn more about the process of asserting API compatibility.

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.