In Relation To

Back to home

Hibernate Validator 9.0.0.Beta2 is out

Posted by    |       Hibernate Validator Releases

We just published Hibernate Validator 9.0.0.Beta2, the first release of the new 9.0 series of Hibernate Validator.

This series targets Jakarta EE 11. It is the implementation of the Jakarta Validation 3.1. It also introduces new constraints, removes the integration of the Security Manager, provides the BOM for simpler dependency management, includes dependency updates, and makes other improvements and bug fixes.

In case you are wondering how it is that the second beta release is the first release in the series, it is because of the testing of the new release process that the first beta wasn’t correctly published. Hence, please ignore the 9.0.0.Beta1 version. We want to apologise for any inconvenience this may cause you and thank you for your understanding.

While this release of Hibernate Validator already includes all the features and bug fixes planned for the 9.0 series, and no significant changes are planned, we are still waiting for some of the dependencies to release their final versions before we can publish a CR or a Final version of Hibernate Validator.

What’s new

Jakarta EE 11 and Jakarta Validation 3.1

The 9.0 series is specifically intended to target the Jakarta EE 11 and implement the Jakarta Validation 3.1. The 3.1 update of the specification does not bring many changes:

  • The minimum required Java version is set to 17.

  • The rename of the specification from Jakarta Bean Validation to Jakarta Validation.

  • The clarification on the record validation, which has been supported by Hibernate Validator for some time.

Dependency upgrades

Jakarta Validation (HV-1979)

Hibernate Validator now implements Jakarta Validation 3.1.

Jakarta Expression Language (HV-2015)

Hibernate Validator now uses the Jakarta Expression Language 6.0. Users wanting to rely on this expression language for message interpolation must include its implementation, e.g. Expressly.

Jakarta Annotation/Jakarta Interceptor/Jakarta Injection/Jakarta Contexts and Dependency Injection(HV-2015)

Hibernate Validator now uses the Jakarta Annotation 3.0, Jakarta Interceptor 2.2, Jakarta Injection 2.0 and Jakarta Contexts and Dependency Injection 4.1.

Others

  • HV-1982: Upgrade to Javax Money 1.1.

  • HV-1983: Upgrade to Classmate 1.7.0.

  • HV-1985: Upgrade to Joda Time 2.12.7.

  • HV-1982: Upgrade to JBoss Logging 3.6.0.

New constraints

This release also brings new constraints.

Country-specific South Korean RRN constraint

The new constraint @KorRRN validates that the character sequence is a valid Korean resident registration number. This constraint also provides an optional attribute ValidateCheckDigit validateCheckDigit() that allows user to specify whether the check digit should be computed and validated. RRNs issued prior to October 2020 use the check digit, while the ones issued after don’t.

@KorRRN (1)
String rrn;
// ...
@KorRRN(validateCheckDigit = KorRRN.ValidateCheckDigit.ALWAYS)  (2)
String rrn;
1 Using a default configuration of the Korean resident registration number constraint, where the check digit is not validated.
2 Using a Korean resident registration number constraint, where check digit validation is required to pass.

Thanks to Taewoo Kim for contributing this constraint.

Bitcoin address constraint

The new @BitcoinAddress constraint validates that the corresponding string is a well-formed BTC (Bitcoin) address. This constraint provides a BitcoinAddressType enum with the list of address types it can validate. By default, BitcoinAddressType.ANY is used, which allows validating all the other address types listed in the BitcoinAddressType enum.

@BitcoinAddress (1)
String address;
// ...
@BitcoinAddress({ BitcoinAddressType.P2TR, BitcoinAddressType.P2PKH }) (2)
private String address;
1 Using a default configuration of the @BitcoinAddress constraint, where all address types listed in the BitcoinAddressType are considered valid.
2 Applying the @BitcoinAddress constraint where the P2TR and P2PKH addresses are considered valid.

Thanks to José Yoshiriro for contributing this constraint.

Alphanumeric CNPJ

Starting January 2026, CNPJ, a Brazilian corporate taxpayer registry number (Cadastro de Pessoa Jurídica), will begin using an alphanumeric format instead of the simple numeric one that is currently used. To address the transition, a new optional format parameter is introduced to allow validating the alphanumeric format.

@CNPJ (1)
String cnpj;
// ...
@CNPJ(format = CNPJ.Format.ALPHANUMERIC) (2)
private String cnpj;
1 Using a default configuration of the @CNPJ constraint, where the numeric-only format is considered as valid.
2 Applying the @CNPJ constraint where the alphanumeric registry numbers are considered as valid.

Thanks to Marcos Vinícius da Silva for bringing up the planned change to the format of the CNPJ.

Hibernate Validator BOM

Hibernate Validator now offers a BOM providing dependency management for all of its published artifacts. It can be imported as part of your dependency management to keep the versions of Hibernate Validator artifacts aligned:

<dependencyManagement>
    <dependencies>
        <!-- Import Hibernate Validator BOM to get all of its artifact versions aligned: -->
        <dependency>
            <groupId>org.hibernate.validator</groupId>
            <artifactId>hibernate-validator-bom</artifactId>
            <version>{hibernateValidatorVersion}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <!-- Any other dependency management entries -->
    </dependencies>
</dependencyManagement>
<!-- ... -->
<dependencies>
    <!-- Declare dependencies -->
    <dependency>
        <groupId>org.hibernate.validator</groupId>
        <artifactId>hibernate-validator</artifactId>
        <!-- The version is managed by the BOM above -->
    </dependency>
    <dependency>
        <groupId>org.hibernate.validator</groupId>
        <artifactId>hibernate-validator-cdi</artifactId>
        <!-- The version is managed by the BOM above -->
    </dependency>
    <!-- Any other dependency entries -->
</dependencies>

Removal of the Security Manager integration

With the security manager being deprecated without an alternative for some time now, we took the opportunity provided by the specification requirement of the minimum Java version to remove the integration of the Security Manager from Hibernate Validator.

Other improvements and bug fixes

  • HV-1328: Add an option to validate class-level constraints only if all property constraints are valid.

  • HV-1978: Fix a bug where the expression language level may be incorrectly propagated to an iterable node.

  • HV-1971: Fix a bug where CNPJ with all digits the same was considered valid.

  • HV-1946: Fix a problem where the path may get corrupted when a custom value extractor uses null as the name of an iterable node.

  • HV-2008: Remove the AssertJ version alignment from Hibernate Validator test utils on the one defined by Jakarta Validation TCK and use the current AssertJ release. This has been requested a few times as users use the test utils to test their custom constraints.

And more. 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 upcoming 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.0 is most cases a drop-in replacement for 8.0, assuming you also upgrade the other Jakarta EE 11 related dependencies. 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