Jakarta Validation

The 3.1 update of the specification, compared to 3.0, brings the following changes:

Jakarta Validation 3.1 will be a part of the Jakarta EE 11 platform, to be released later.

Don’t wait and try out the new release yourself! Just get the Hibernate Validator implementation, read the Getting started section of its reference guide. You also can read the complete specification as well as the API docs.

By now, you’ll probably have heard about all the new features added in Bean Validation 2.0. Just in case you haven’t, here’s a quick summary:

Bean Validation 2.0 will also be part of the Java EE 8 platform, to be released later this summer.

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.

I’d like to shout out a huge "Thank you" to everyone helping with the work on Bean Validation 2.0:

It has been a true pleasure and honor for me to make the new spec a reality together with such a fantastic community!

Don’t wait and try out the new release yourself! Just download the reference implementation Hibernate Validator and read the Getting started section of its reference guide. You also can read the complete specification as well as the API docs.

Thanks to Guillaume’s tireless work, the Bean Validation TCK has grown substantially since 1.1. There are now 685 assertions overall, out of which 627 are testable. 99.04% of them are covered by 2133 tests overall. The added tests cover all the new Bean Validation 2.0 features, so we feel very confident that the TCK ensures correctness of implementations passing it.

Also the tooling for producing the TCK has been improved significantly: sentences or phrases of the spec document can be marked as relevant for the TCK with the help of AsciiDoc roles. A special Maven plug-in then is used to generate a report of all those marked assertions, allowing to link them to tests of the TCK and making it easy to identify assertions without corresponding tests yet.

We’ll discuss the entire TCK tool chain in more depth in a separate blog post. If you are interested in the TCK and would like to learn more about its development, the appeals process and other related things, check out the TCK reference guide.

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.

With the submission of the specification to the JCP for the Final Approval Ballot, the work on Bean Validation 2.0 is done more or less. If you’d like to help, reviewing the specification changes would be the best thing to do at this point. You also could try out the reference implementation Hibernate Validator in your applications and let us know how it works.

Also tell us about ideas and wishes for a future 2.1 release of the spec. We are eager to learn about your requirements, so we can explore any new features in the reference implementation.

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.

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:

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.

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.

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.

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.

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.

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:

Your efforts are greatly appreciated!