Bean Validation 2.0 CR 2 released
I’m very happy to announce the CR 2 release of the Bean Validation 2.0 spec!
The CR 2 is an update to the Proposed Final Draft (CR 1), addressing remarks and comments from reviewing all the changes. The updated spec document can be found here. To see the changes applied since the CR 1, check out this colored diff. If you’d like to see all the changes since Bean Validation 1.1, take a look at this diff. The updated API is available on Maven Central, using the GAV coordinates are javax.validation:validation-api:2.0.0.CR2.
What’s new since CR 1?
Given we are in the CR phase, most of the changes of this release naturally fall into the category of bug fixes, wording clarifications, formatting and other similar improvements. Reviewing the work done so far, and also working on the reference implementation and the TCK, we’ve decided to include two improvements to the API, too:
-
ConstraintDescriptor#validateUnwrappedValue()got renamed intogetValueUnwrapping()(BVAL-674). The original method name sounded like a "command", whereas the new name makes clear it’s a "query" kind of method; also the members of the returned enum have been adapted to be in sync with the correspondingUnwrappingpayload type names. We’ve also added a methodConstraintDescriptor#unwrap(Class), which will let providers expose additional functionality via extension interfaces, e.g. to explore new features which then can be standardized in a future spec revision. -
@ConvertGroup#from()has a default value ofDefault.classnow (BVAL-689). This simplifies group conversions in the common case where the default group is converted into another group.
Another interesting change is BVAL-613:
when using the reference API JAR with the Java 9 module system, it will have the module name "java.validation" (following the recommendation in the spec appendix).
This is done using the Automatic-Module-Name manifest header defined by Java 9.
Other changes include JavaDoc improvements and more clearly separating API types from examples in the spec. The complete list of all issues resolved for the CR 2 release can be found in the BVAL JIRA project. Corresponding releases of our reference implementation Hibernate Validator 6 and the TCK are also done today.
What’s new in Bean Validation 2.0?
The focus of Bean Validation 2.0 is supporting and taking advantage of Java SE 8.
For instance type annotations are used to validate the elements of generic containers: List<@NotNull @Email String> emails.
There are new built-in constraints (@NotBlank, @NotEmpty, @Email, @FutureOrPresent, @PastOrPresent, @Positive, @PositiveOrZero, @Negative and @NegativeOrZero) and all built-in constraints are repeatable annotations now.
Bean Validation 2.0 also supports the new Java 8 date and time types (JSR 310), the property types defined by JavaFX (StringProperty etc.) as well as java.util.Optional.
To learn more about all the new features in Bean Validation 2.0, check out this presentation which I recently gave at the jdk.io conference.
What can you do to help?
We’ll hand over the specification to the JCP for the Final Approval Ballot early next week. For the FAB release, we don’t expect any significant changes over today’s CR 2. If you’d like to help, reviewing the specification changes would be the best thing to do at this point. Also it’d be of great help if you tried out the reference implementation in your applications and let us know how it works. Any feedback is welcomed!
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: be it to the API, the spec document, the TCK or the reference implementation. If you are interested, you can find out all the details to get started in the contribution guide.
Proposed Final Draft of Bean Validation 2.0 released
I’m very happy to announce that Bean Validation 2.0 has published its Proposed Final Draft (CR 1)!
You can find the PFD right here on beanvalidation.org as well as on JSR 380’s pages on jcp.org. We’ve also prepared a colored diff with all the changes since Bean Validation 1.1. The updated API is available on Maven Central, using the GAV coordinates are javax.validation:validation-api:2.0.0.CR1. Alternatively, it’s part of the ZIP that can be downloaded from from jcp.org.
What’s new in Bean Validation 2.0?
The focus of Bean Validation 2.0 is supporting and taking advantage of Java SE 8.
For instance type annotations are used to validate the elements of generic containers: List<@NotNull @Email String> emails.
There are new built-in constraints (e.g. @NotBlank, @NotEmpty, @Email, @Positive and @Negative) and all built-in constraints are repeatable annotations now.
Bean Validation 2.0 also supports the new Java 8 date and time types (JSR 310), the property types defined by JavaFX (StringProperty etc.) as well as java.util.Optional.
To learn more about all the new features in Bean Validation 2.0, check out this presentation which I recently gave at the jdk.io conference.
What’s new since the Public Review Draft?
Since the Public Review Draft (Beta 2) we’ve primarily focused on improving the new Bean Validation 2.0 features, e.g. by clarifying ambiguities in the spec, fixing bugs in the API, adding more examples etc.
In terms of API changes, we’ve followed up on our community survey on the new built-in constraints @Positive and @Negative
and removed the strict() attribute in favor of separate annotations: @PositiveOrZero and @NegativeOrZero.
As suggested by the community feedback, we’ve found that those separate annotations improve readability of code using the constraints.
In order to stay consistent, we’ve also removed orPresent() from @Past and @Future in favor of @PastOrPresent and @FutureOrPresent.
We think the same argument of readability applies; if you have any thoughts on these changes, please let us know.
Another API change (BVAL-655) relates to how container element constraints are exposed in the constraint metadata API. In case an overriding method of a sub-type specializes the return type of the overridden method (co-variant return type) it’s now possible to obtain the constraint metadata for the return type of the super-type method as well as of the sub-type method. Refer to the spec for the complete metadata API definition and an extensive example of its usage.
The complete list of all 38 issues resolved for the CR 1 release can be found in the BVAL JIRA project. Corresponding releases of our reference implementation Hibernate Validator 6 and the TCK can be expected within the next few days.
What can you do to help?
The Proposed Final Draft is pretty much what the expert group thinks should make up Bean Validation 2.0, i.e. it should be considered feature-complete. Any further changes will essentially be bug fixes, further clarifications in the wording, formatting and other polishing. If you’d like to help, reviewing the specification changes would be the best thing to do at this point. Also it’d be of great help if you tried out the reference implementation in your applications and let us know how it works. Any feedback is welcomed!
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: be it to the API, the spec document, the TCK or the reference implementation. If you are interested, you can find out all the details to get started in the contribution guide.
Finally, let me say a huge "Thank You" to all the fine folks who helped to deliver this Proposed Final Draft:
-
Matt Benson, Emmanuel Bernard, Yoann Rodiere, Marco Molteni, Otávio Gonçalves de Santana, Michael Nascimento and everyone else who sent in comments and review remarks on the spec
-
Guillaume Smet who worked tirelessly to keep up the TCK and the reference implementation with the latest changes
Your efforts are greatly appreciated!
Update to the Bean Validation 2.0 Public Review Draft
While the Bean Validation 2.0 spec (JSR 380) has been put up for Public Review last month, we’ve continued to address some more outstanding issues, added some clarifications etc.
Of course we wanted to get out these improvements as quickly as possible, so we’ve published an update to the Public Review draft (the JCP rules explicitly foresee the possibility of updates during the Public Review phase). The updated draft can be found here on beanvalidation.org or you can download it from jcp.org.
As always the updated API is deployed to Maven Central, using the GAV coordinates are javax.validation:validation-api:2.0.0.Beta2. Alternatively, it’s part of the ZIP that can be downloaded from from jcp.org.
What has changed since the original Public Review Draft?
Value extractors got more flexible and can extract values from non-generic wrapper types now.
This allows to put all the constraints for numeric types (e.g. @Min, @Max, @DecimalMin, @DecimalMax etc.) to the optional numeric wrapper types in Java 8: OptionalInt, OptionalLong and OptionalDouble (BVAL-579).
Also other JVM languages with their own numeric types benefit from that, as one can define value extractors for such types and apply all existing numeric constraints to them.
The key to this is the new attribute @ExtractedValue#type() which allows to specify the type of the wrapped element for extractors of non-generic types.
Another improvement related to constraints on the elements of (generic) containers is the possibility to build property paths leading to a container element using the node builder API exposed via ConstraintValidatorContext (BVAL-592).
For instance this will let you declare the container type and type argument index of a container element from within a custom class-level constraint validator.
The following validator for the ValidUser constraint will ensure that an entry for the WORK key is in the addresses map if the user’s type is EMPLOYEE.
If not, it will create a property path pointing to the map’s value, with the container type (Map.class) and type argument index (1, representing the V type parameter, as it’s about the map value):
@ValidUser
public class User {
private UserType type;
private Map<AddressType, Address> addressesByType;
// getters, setters etc. ...
}@Constraint(validatedBy=UserValidator.class)
public @interface ValidUser {
// constraint attributes ...
}public class UserValidator implements ConstraintValidator<ValidUser, User> {
@Override
public boolean isValid(User user, ConstraintValidatorContext context) {
context.disableDefaultConstraintViolation();
if ( user.getType() == UserType.EMPLOYEE &&
user.getAddressesByType().get( AddressType.WORK ) == null ) {
context.buildConstraintViolationWithTemplate( "Work address needed for employee" )
.addContainerElementNode( "addressesByType", Map.class, 1 )
.inIterable()
.atKey( AddressType.WORK )
.addConstraintViolation();
return false;
}
return true;
}
}One further improvement to mention is that the specification now recommends the module name "java.validation" (BVAL-517), should Bean Validation providers wish to distribute the API as a module for the Java Platform Module System (JPMS) as currently developed under JSR 376. This could be used within a module-info.java descriptor or via the manifest entry "Automatic-Module-Name" when preparing the module to be used as an automatic module.
Note that this is a non-binding recommendation as of Bean Validation 2.0. A mandatory module name (which could be "java.validation" or something else) — and potentially other requirements relating to the module system — will be mandated in a future revision of the spec, once the module module system has been finalized and best practices around modules have emerged.
The complete list of all issues can be found in the release notes. There are also HTML diffs which highlight what has changed since the original Public Review Draft (2.0.0.Beta1) and since Bean Validation 1.1.
New releases of reference implementation and TCK
Together with the specification we’ve also released a corresponding version of the reference implementation Hibernate Validator 6. Refer to the announcement blog post for more details. This release lets you try out all the new features added in Bean Validation 2.0.
Also the TCK (test compatibility kit) has been updated and released. You can learn more in the TCK documentation and the release notes.
What can you do to help?
The Public Review phase still runs for a few more days, followed by the Public Review Ballot (the voting by the JCP executive committee) until June 12th. So it’s the perfect time for reviewing the spec changes, we are very curious about your feedback. Also it’d be of great help if you tried out the reference implementation in your applications and let us know how it works. Any feedback is appreciated!
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.
Survey - Behavior of @Positive and @Negative constraints
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
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.
Latest news
Stay up to date, subscribe to the news feed.