In Relation To

Back to home

Hibernate Validator 9.0.0.Final 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 are pleased to announce the release of Hibernate Validator 9.0.0.Final.

Compared to Hibernate Validator 8.0 this series is the implementation of the Jakarta Validation 3.1 and targets Jakarta EE 11. It also introduces new constraints, removes the integration of the Security Manager, provides the BOM for simpler dependency management, removes a few constraints, configuration properties and APIs, which have been deprecated for several major versions and stops publishing relocation POMs for the old org.hibernate group id. There are also a few other improvements, bug fixes and dependency updates.

What’s new

For a summary of all new features and improvements since 8.0, head to the dedicated page on hibernate.org, or check a more detailed list below.

Jakarta EE 11 and Jakarta Validation 3.1

As a reminder: the 9.0 series targets Jakarta EE 11 and implements 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 specification was renamed from Jakarta Bean Validation to Jakarta Validation.

  • Validation of Java record types was clarified (this 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-2045: Upgrade to JBoss Logging 3.6.1.

  • HV-2093: Upgrade to Joda Time 2.14.0.

  • HV-2090: Upgrade to OpenJFX 17.0.14.

  • HV-2090: Upgrade to Paranamer 2.8.1.

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.

Removal of the relocation POMs

With Hibernate Validator 9.0, we are no longer publishing relocation POMs for the group id org.hibernate previously used by the following artifacts:

  • org.hibernate:hibernate-validator-annotation-processor

  • org.hibernate:hibernate-validator-cdi

  • org.hibernate:hibernate-validator

These relocation POM files were introduced back in 2017 to help users gradually migrate to the new org.hibernate.validator group id.

See the migration guide for more details on migration from previous versions.

Removal of the deprecated APIs

There were a few constraints, configuration properties, and public API methods/classes that have been deprecated for several major versions now, with available alternatives to migrate to. With this new major version of Hibernate Validator some of these are removed. For a detailed list of removed deprecated items see the migration guide.

OSGi integration clarification

Starting with Hibernate Validator 9.0, the Hibernate team no longer tests nor maintains the OSGi integration. For users who would want to experiment with Hibernate Validator in an OSGi environment, we will keep the existing manifest entries in place as they were.

Even though we no longer maintain the Hibernate Validator OSGi integration, we do encourage the community members interested in it to come forward with pull requests if they encounter some issues. In such a case, we will try to guide the submitter through the contribution process and assess the suggested patch for inclusion in the build.

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.

  • HV-1931: Address a problem with Hibernate Validator version printed as null in the logs when running on a module path.

  • HV-1942: Update the DefaultGroupSequenceProvider interface to be aware of the type it is applied to. This should allow a single implementation of the DefaultGroupSequenceProvider to be applied to more than one type.

  • HV-1955: Update the implementation of the @NotBlank constraint to rely on the String#isBlank().

  • HV-2053: Add translation of Validation Messages for Azerbaijani language. Thanks to Shamkhal Maharramov for contributing the translation file.

  • HV-2067: Fix a problem with the @UUID constraint, where UUIDs could have been incorrectly validated for explicitly specified versions.

  • HV-2031: Make PredefinedScopeHibernateValidatorFactory aware of types for which constraint mappings are defined only in XML

  • HV-2029: Fix an issue when an exactly the same ConvertGroup is defined on both original and overridden methods in a class hierarchy leads to a constraint declaration exception.

  • HV-2018: Fix an issue related to validating values via Validator#validateValue(..), when the supplied bean type is an interface.

  • HV-1931: Address a problem with Hibernate Validator version printed as null in the logs when running on a module path.

  • HV-1942: Update the DefaultGroupSequenceProvider interface to be aware of the type it is applied to. This should allow a single implementation of the DefaultGroupSequenceProvider to be applied to more than one type.

  • HV-1955: Update the implementation of the @NotBlank constraint to rely on the String#isBlank().

  • HV-2053: Add translation of Validation Messages for Azerbaijani language. Thanks to Shamkhal Maharramov for contributing the translation file.

  • HV-2067: Fix a problem with the @UUID constraint, where UUIDs could have been incorrectly validated for explicitly specified versions.

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 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 in most cases is a drop-in replacement for 8.0, assuming you also upgrade the other Jakarta EE 11 related dependencies and were not relying on the removed deprecated APIs. 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