Bean Validation 2.0 is up for Public Review
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 jcp.org. 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 jcp.org.
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:
-
5.7.5. Value extractor resolution
-
6.2. ConstraintViolation (changes around property paths in
ConstraintViolationobjects) -
7.11. ContainerDescriptor and ContainerElementTypeDescriptor (metadata API extensions)
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
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
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:
<dependency>
<groupId>org.hibernate.validator</groupId>
<artifactId>hibernate-validator</artifactId>
<version>6.0.0.Alpha1</version>
</dependency>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.Durationvia two new constraints,@DurationMinand@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
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 jcp.org. 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 jcp.org 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.:
@Future
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():
@Past(orPresent=true)
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 -
ValidatorFactoryextendsAutoCloseable, allowing to use it intry-with-resourcesblocks
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!
Bean Validation 1.1 is a spec
It's now official, these couple of years of work have made it into an official JCP specification. Bean Validation is also part of Java EE 7 which has been approved too a few of days ago.
We have already discussed the features at great length here but to do a short summary:
- support for method and constructor validation (via CDI, JAX-RS etc)
- integration with CDI (
ValidatorandValidatorFactoryinjectable,ConstraintValidatorinstances being CDI beans and thus accept@Inject, etc) - EL expressions based error messages
- group conversion in object graphs
I would like to thank the expert group and the community at large (without your input there would be no 1.1), Hardy and Gunnar that worked round to clock on the spec, the RI and the TCK and deliver everything on time, Pete for being my springboard when all hell broke lose and the folks at Oracle who worked with us to integrate Bean Validation with the rest of the Java EE ecosystem whether it be spec, implementation or TCK.
Go grab Hibernate Validator, the RI. The team has even spent an extra couple of weeks to deliver a nice documentation. And if you can't sleep, go read the specification itself.
Latest news
Stay up to date, subscribe to the news feed.