Survey - Where do you use constraints on parameterized type?

by Emmanuel Bernard on 23 Nov 2016 feedback

For Bean Validation 2, we are working on the support for Collection<@Email String>, Optional<@Min(3) Integer> etc. This has been a very common request and with Java 8 type use support, we can how achieve this. However, we need your feedback on how you would use such feature.

Some context

We have support not only for collections, Optional, Java FX properties but also for what we call custom parameterized containers. We are wondering a few things about custom parameterized containers, namely how common they are. This will affect the trade-offs we want to make on the design of that feature.

What is a container?

A container is a type that wraps and exposes one or several values. The values is what you want to apply your constraints on. And the container is parameterized because at use site, you can declare what type it actually contains. For a Set<@Email String>, we want to make sure every string in the set is an email.

Another less obvious example is a tuple class.

public class Pair<V1,V2> {
    V1 getV1() { ... }
    V2 getV2(); { ... }

public class Address {
    // street1 is mandatory, street2 is optional
    // represented via a Pair object
    Pair<@NotNull @Size(max=250) String, @Size(max=250) String> streetFields;

Other examples are:

  • a tree structure containing specific object types

  • Guava’s Multimap (or any multimap for that matter)


We are wondering which type of parameterized containers you have in your code base and how likely you are going to apply constrains on their contained value. The form is a list of short questions that will help us get a better picture.

Here is the link to the form in a separate page or use it directly embedded below.

Many thanks!


Feedback needed - Which constraints should be added?

by Gunnar Morling on 15 Sep 2016 feedback

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!


Bean Validation 2.0 - A new JSR is born!

by Gunnar Morling on 15 Jul 2016 news

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

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!


Bean Validation TCK 1.1.4.Final released

by Gunnar Morling on 18 Jun 2015 tck

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.


Bean Validation TCKs now with signature files for Java SE 8

by Gunnar Morling on 18 Jun 2014 tck

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.