Survey - Behavior of @Positive and @Negative constraints

by Gunnar Morling on 12 May 2017 feedback

Based on our previous survey we’ve recently added the new constraints @Positive and @Negative to the Bean Validation spec. Now we’ve had an interesting discussion on some details of those constraints, e.g. should 0 (zero) be considered as a valid value by default? I.e. what’s the more common use case, to consider 0 as valid or not?

So we thought let’s make another survey to gauge the community feedback on those issues. You’d help us very much by answering the two questions below, you won’t need more than a minute.

If you have any other thoughts you’d like to share, either add an answer to the free-text question or post a comment below. The survey will be open until the end of next week.

Thanks a lot for your help!


Bean Validation 2.0 is up for Public Review

by Gunnar Morling on 26 Apr 2017 release

It’s with great pleasure that I’m announcing that Bean Validation 2.0 (JSR 380) is entering the Public Review phase!

You can read the Public Review Draft right here on this website or download it from We are also publishing HTML diffs, making it very easy for you to track the changes since Bean Validation 1.1 and since the previous 2.0 release (Alpha2).

The updated API is deployed to Maven Central, its coordinates are javax.validation:validation-api:2.0.0.Beta1. Alternatively, it’s part of the ZIP that can be downloaded from from

A huge thank you goes to everyone in the expert group and in the wider community who helped to make this release happen! Whether it’s discussions on the mailing list, reviewing pull requests, sending in your own patches or lobbying for the new spec revision - it’s your contributions that make the difference.

What’s New?

Since the Alpha2 release, we’ve mainly focused on consolidating the container element validation feature (think List<@Email String> emails); the previous appendix describing this feature has been removed and its contents have been merged into the actual specification chapters.

The related chapters and sections in the spec are:

Note that we have decided to remove the support for container element validation of arrays which had been part of the previous proposal.

As we found out, there’s an ambiguity when type annotations are used on an element like a field of a Java bean: in this case it isn’t clear whether the annotation applies to the declaration itself (i.e. the array) or the component type of the array (i.e. the array elements). We felt that it is better to play it safe and let Bean Validation implementations experiment with this first and bring back array support later on. The names and semantics used in the spec and API should be generic enough so that they should suit for the array case, too, should we decide to add it down the road.

Together with the Java EE expert group we’ve also worked on a clarification regarding the location of the Bean Validation deployment descriptor. The Bean Validation spec only ever meant to support META-INF/validation.xml for this, but the Java EE spec unfortunately mentioned WEB-INF/validation.xml for web modules. While this has never been supported by the Bean Validation reference implementation and most application servers, a community member thankfully brought the inconsistency between the specs to our attention recently. The issue has been fixed by having the Java EE spec refer to Bean Validation for the descriptor location, which clearly says that it always is META-INF/validation.xml. Servers which happen to support the alternative location, should phase out support for this, e.g. by raising a warning when detecting its usage and recommending to use the standardized location.

The complete list of changes in the Beta1 release can be found in the change log.

To learn more about all the new features we’ve added to Bean Validation 2 so far, check out the previous posts in this blog, the What’s new section in the spec draft or simply the full HTML diff with all the changes.

Another helpful resource may be the slides of a (German) presentation on Bean Validation 2.0 I recently did at JavaLand.

What’s next?

Currently we’re focusing on updating the reference implementation to the latest spec changes. You can expect a new release of Hibernate Validator 6 some time next week. This will let you experiment with all the new features and explore them in more depth.

We are also planning to pick up some remaining loose ends around container element validation and - if we get to it - the separation of the message interpolation algorithm from the retrieval of messages from resource bundles (BVAL-217).

There is a couple of issues assigned to the Beta2 release already. If you think something else should really be in there, please let us know as soon as possible!

Apart from work on the spec itself and the reference implementation there is also the TCK (the test suite all implementations need to run in order to ensure their compatibility). There are quite a few tests to add for the recently added features. We already got many within the Hibernate Validator’s test suite, so we can simply move over those. But there also some new tests to be written.

The Public Review runs until May 27th, followed by Public Review Ballot (the voting by the JCP executive committee) until June 12th. If all goes well, we’ll release the Proposed Final Draft soon after that, followed by the submission to the Final Approval Ballot in July, aligning with the overall schedule for Java EE 8.

What can you do to help?

Reviewing the spec changes (all or part of them) would be super-awesome! There is a very handy HTML diff (did I mention it before?) which makes it easy to spot all the changes since Bean Validation 1.1.

Another thing you can do is to try out the reference implementation in your applications (ideally the new version to be released next week). Do the new features work as intended? Is anything missing, not behaving as described in the spec or generally just not working as you think it should? Then please tell us. The more feedback we get, the better.

To post your feedback, just add a comment below, send a message to our mailing list or post in the Bean Validation forum. If you find a bug or have a specific feature request, please raise it in the issue tracker.

Everything in Bean Validation is open source, so you also can send in actual patches: to the API, the spec document or the TCK. If you are interested, you can find out all the details to get started in the contribution guide.


Bean Validation 2.0 Alpha2 is out

by Gunnar Morling on 31 Mar 2017 release

I’m happy to announce the release of the Alpha2 release of the Bean Validation 2 API and specification.

This release contains several improvements and clarifications around the validation of container elements (think List<@Email String>):

  • Custom value extractors can now be passed in when bootstrapping a validator factory or validator (via API or XML)

  • Value extractors are detected via the Java service loader mechanism (e.g. allowing libraries to ship their own extractors for custom collection types)

  • Property paths for constraint violations on container elements will now contain a node of the new type CONTAINER_ELEMENT

  • Container element constraints can be specified in XML mapping descriptors

There are also some new constraints, as per the community feedback on the survey we did last year:

  • @NotEmpty, @NotBlank

  • @Email

  • @Positive, @Negative

The first three have been part of the reference implementation for a long time and have been promoted to the spec due to their frequent usage. The latter two are new constraints which address the very common use case of mandating that a numeric value should be positive or negative. It’s configurable via the strict() attribute whether 0 should be considered as valid or not.

You can find the complete list of addressed issues in JIRA. The spec text of the Alpha2 release is published here. The GAV coordinates of the API JAR are javax.validation:validation-api:2.0.0.Alpha2.

TCK update

Together with the spec we also released a new version of the Bean Validation TCK for testing the new features. Its coordinates are org.hibernate.beanvalidation.tck:beanvalidation-tck-tests:2.0.0.Alpha3 (it should be synced to Maven Central soon).

If you are wondering why the TCK is at Alpha3 already, that’s because of a glitch with the Alpha2 release which wouldn’t allow to run the TCK in a container. Hence we released the Alpha3 version right after that.

Trying it out yourself

In order to try out the latest Bean Validation features, grab this week’s release of the reference implementation, Hibernate Validator 6 Alpha2.

It supports the Alpha2 version of the spec and some things more. Refer to the announcement post for all the details. Please give it a try and let us know about your thoughts on these changes as well as any other things related to Bean Validation.

We are now working towards the Public Draft of the spec (to be expected in April). The Public Draft will mostly polish the work done so far. Most prominently, the container element validation feature, which currently is an appendix to the spec, will be incorporated in the actual specification sections.

We’ve also planned to address some other feature requests, like splitting up the notion of message interpolation and retrieving message bundles. If there are other things you’d like to see addressed in Bean Validation 2.0, please get in touch quickly, the clock is ticking :)


First Alpha of Bean Validation 2.0 Reference Implementation Available

by Gunnar Morling on 16 Feb 2017 release

A few days after the release of the Bean Validation 2.0 Early Draft 1 there is now also a first version of the reference implementation available.

If you are using Apache Maven, add the following dependency to your pom.xml to give it a test ride:


The 6.0.0.Alpha1 release provides all the functionality of the Early Draft 1. In addition there is support for

  • nested type argument constraints, e.g. Map<String, Size(min=1) List<@NotNull Item>> itemsByCategory; this addresses open question #1 from the proposal for the validation of container elements

  • definition of constraints using Lambda expressions and method references

  • validation of java.time.Duration via two new constraints, @DurationMin and @DurationMax

If you think those things should be added to the spec, please let us know. Your feedback on these features as well as all the other Early Draft 1 additions will be much appreciated!

Check out the original Hibernate Validator release announcement for all the details.


Bean Validation 2.0 Early Draft 1 is Out

by Gunnar Morling on 14 Feb 2017 release

I’m very happy to announce the first Early Draft Review of JSR 380, Bean Validation 2.0!

This Early Draft comprises all the spec changes done so far and it’s a great opportunity for us to get feedback from the community at large. You can read the spec draft either directly on this website or download it from A GitHub diff showing all the changes to the spec’s AsciiDoc document done so far (sans some typo and style fixes) is available here.

The updated API can be downloaded from from or fetched from Maven Central using the coordinates javax.validation:validation-api:2.0.0.Alpha1.

What’s New?

The main theme of Bean Validation 2.0 is support for and taking advantage of Java 8. This concerns new language features such as type use annotations as well as library additions.

An example of the latter is the support for the new Java 8 date and time API (JSR 310). You can now use @Past and @Future on javax.time types such as Instant, LocalDate etc.:

private LocalDate deliveryDate;

For types that don’t represent a specific instant but rather an interval of time, you can configure that the current month, year etc. should be considered valid, too, using the new attribute orPresent():

private final Year inceptionYear = Year.of( 2017 );

An example where Bean Validation benefits from new language features in Java 8 is the new mechanism for validating the elements of Collection, Optional and other container types. By annotating type arguments of generic types you can now put constraints to the container elements (as opposed to the container itself):

List<@NotNull @Email String> emails;

Also cascaded validation (@Valid) gets more powerful with that. E.g. you can now perform a cascaded validation of map keys and map values (only values were supported before):

Map<@Valid Customer, @Valid Address> primaryAddressByCustomer;

Another use case for this is validation of values wrapped in a java.util.Optional:

Optional<@Past LocalDate> getRegistrationDate();

We’ve baked in support for type argument constraints on types such as Iterable, Map, Optional and some more, but this isn’t a fixed list. You can plug in custom implementations of the ValueExtractor contract which will allow you to put type argument constraints to other collection types (e.g. Google Guava’s Multimap) or even collection classes from other JVM languages such as Ceylon.

What else?

Support for JSR 310 and type argument constraints are just two of the new features. Some other changes are:

  • All constraints and a few other Bean Validation annotations are repeatable

  • Method parameter names to be shown in error messages are obtained using reflection (if enabled)

  • ConstraintValidator#initialize() is a default method, simplifying the implementation of constraint validators which don’t need to access the annotation state

  • ValidatorFactory extends AutoCloseable, allowing to use it in try-with-resources blocks

To learn more about the changes we’ve done so far, either check out our progress report from a few weeks ago or the specification document itself.

What’s next?

The next step will be to bring the Bean Validation reference implementation, Hibernate Validator, up to par with the Early Draft 1. Most of the work for this has been done already, so you can expect the first Alpha release of Hibernate Validator 6 later this week. This will allow you to play around with all the new features and explore them in more depth.

This release will add some features on top of what is in spec so far, e.g. support for defining constraints using Lambda expressions. We felt it’d be good to gain some experience with this and some other features by putting an implementation into the hands of users before adding them to the spec. More details on that once the reference implementation is out.

In terms of spec changes, some of the next features we are planning to work on are:

  • Adding some new constraints as per our recent survey, e.g. @Email, @NotEmpty, @NotBlank

  • Ability to validate an object and a list of changes (BVAL-214) which would be useful for validating class-level constraints in UI use cases

  • Separating the message interpolation algorithm from the retrieval of messages from resource bundles (BVAL-217)

What can you do to help?

Glad you asked :)

As in its previous versions, Bean Validation 2.0 is developed fully in the open. So we count on your feedback on the Early Draft as well as any other ideas or suggestions you may have around Bean Validation. One area where we are looking for feedback specifically is the proposal for container value validation. There is a list of open questions towards the end of that section. If you have thoughts on any of those, please let us know.

To get a discussion started, just post a comment below, send a message to our mailing list or post in the Bean Validation forum. If you find a bug or have a specific feature request, please raise them in the issue tracker.

And as Bean Validation is a true open source project, contributing e.g. in form of patches is easy, too. Check out the contribution guide to learn more.

Finally, let me say a big thank you to everyone involved with making the Early Draft happen; your work is much appreciated!