Jakarta Bean Validation

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.

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.

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.