In Relation To

Back to home

Hibernate Validator 9.1.0.Alpha1 is out

Posted by    |       Hibernate Validator Releases

Hibernate Validator is the reference implementation for the Bean Validation specification. For more information, see Hibernate Validator on hibernate.org.

We just published Hibernate Validator 9.1.0.Alpha1, the first release of the new 9.1 series of Hibernate Validator.

This series primarily aims to improve performance. It also contains a few improvements, fixes and dependency updates.

As this release includes significant changes to the processed bean tracking, path implementation and related areas, we encourage users to give it a try, especially if there are non-trivial validation scenarios.

What’s new

Performance improvements

In this version, we have changed the jakarta.validation.Path implementation, approach to processed bean tracking and slightly modified the message interpolation to improve both overall performance and performance of cascading validation when beans require a lot of cascading operations. We plan to publish a more detailed report with benchmark results, so stay tuned if you are interested in the details and numbers.

Deprecating the use of @Valid at the container level

Since Bean Validation 2.0, which introduced type argument constraints, the approach of placing the @Valid annotation at the container level to apply cascading validation to container elements has been considered a "legacy" approach. Users have been encouraged to move their constraints to the type argument level.

Example 1. Legacy approach to cascading validation for container elements
class MyBean {
    @Valid (1)
    List<MyContainerElement> list;
}
1 Cascading validation is requested at the container level, whereas the expectation is that container elements will be considered for cascading, not the container itself.
Example 2. Current approach to cascading validation for container elements
class MyBean {
    List<@Valid MyContainerElement> list; (1)
}
1 Cascading validation is requested at the container element level. This clearly communicates the intention that elements are expected to be cascaded into and not the container itself.

Starting with 9.1, Hibernate Validator will produce warnings during the metadata building step if it detects the legacy approach to cascading validation of container elements. In the future version, this support of Bean Validation 1.0/1.1 legacy behaviour will be dropped. Placing the @Valid at the container level would result in cascading into the container itself rather than into its elements.

There is still some work ahead of us before we can turn off this legacy behaviour. For example, we must address the case where the container does not have type arguments but still requires cascading into its elements. This is currently tracked at the Jakarta Validation specification level through the following issue.

We encourage users to review and update their validation mapping where necessary. Additionally, if you encounter a particular use case that you believe is not covered, please don’t hesitate to contact us.

Extended validation path

This version introduces an extension the jakarta.validation.Path: org.hibernate.validator.path.Path. We identified that there are a lot of use cases that require the leaf node of the path, and to get to it, one usually would need to iterate through the path to get to the very last element:

Example 3. Iterate through the path to get the leaf node
Path path = constraintViolation.getPropertyPath();
// use a for loop to iterate over the path nodes:
Node leaf = null;
for (Node node: path) {
    leaf = node;
}

// request the path node iterator explicitly:
Iterator<Path.Node> nodes = constraintViolation.getPropertyPath().iterator();
Path.Node leafNode = null;
while (nodes.hasNext()) {
    leafNode = nodes.next();
}

This approach might result in unnecessary allocations and operations, especially if the underlying path implementation has a direct reference to the leaf node.

With that in mind org.hibernate.validator.path.Path introduces the getLeafNode() method.

Example 4. Using the Hibernate Validator extension to the jakarta.validation.Path
Path path = constraintViolation.getPropertyPath();
if ( path instanceof org.hibernate.validator.path.Path hvPath ) {
    Node leaf = hvPath.getLeafNode();
        // ...
}

Other improvements and bug fixes

Please see the release notes for a complete list of changes since the previous releases.

How to get this release

Hibernate Validator 9 targets the Jakarta EE 11.

All details are available and up to date on the dedicated page on hibernate.org.

Getting started, migrating

For new applications, please refer to the getting started guide:

For existing applications, Hibernate Validator 9.1 is a drop-in replacement for 9.0. Information about deprecated configuration and API is included in the migration guide.

Feedback, issues, ideas?

To get in touch, use the usual channels:

Back to top