Hibernate Validator

The GetterPropertySelectionStrategy SPI contract has been adjusted. The getGetterMethodNameCandidates() method now returns a List instead of a Set.

Jakarta EE 10

The EL implementation to use is now org.glassfish.expressly:expressly:

<dependency>
   <groupId>org.glassfish.expressly</groupId>
   <artifactId>expressly</artifactId>
   <version>5.0.0-M1</version>
</dependency>

Jakarta EE 9 (a.k.a. the big jakarta.* package change)

XML namespaces changed

@SafeHtml constraint dropped

Expression Language disabled for custom violations by default

Expression Language Bean methods execution disabled for constraints by default

@SafeHtml constraint dropped

Expression Language disabled for custom violations by default

Expression Language Bean methods execution disabled for constraints by default

@SafeHtml has been deprecated and marked for future removal.

@SafeHtml has been deprecated and marked for future removal.

If you are using our CDI integration, be sure that all the beans you want to validate have a Bean Validation annotation (be it a constraint, @Valid or @ValidateOnExecution). If you need to add an annotation, just add a simple @ValidateOnExecution to the class. This limitation was present until 6.0.10.Final and is now back due to a nasty startup time regression of CDI applications.

We removed the StaticFieldELResolver from our javax.el resolver list. This feature was added during the 6.x cycle and never documented. If you want to call methods from your EL expressions, just inject an object containing the methods as a variable.

A few validation messages have been changed to be more consistent. That being said, you should rely on the constraint annotation to categorize your violations rather than on the message.

We fixed an issue with the JPATraversableResolver not being initialized correctly (and thus we we using the default one): the JPATraversableResolver is now used by default in any JPA environment as it should be (thus Hibernate Validator will not validate or cascade lazily loaded properties not already loaded). If it is not the behavior you want, you can override the TraversableResolver for your ValidatorFactory. This regression was introduced in 6.0.3.Final.

We fixed the CDI extension to properly consider the annotations in the hierarchy of a class. Prior to 6.0.10.Final, if the considered class didn’t have any validation related annotations but its class hierarchies did, the annotations in the class hierarchy were ignored. This is no longer the case. Note: it worked OK if the considered class itself had at least one validation related annotation.

The constraint validator payload (incubating feature introduced in 6.0.8.Final) has been moved from the HibernateConstraintValidatorInitializationContext to the HibernateConstraintValidatorContext. See the documentation for more information.

To improve the compatibility with the version previously shipped in WildFly, we reintroduced a few things removed in earlier versions of 6.0:

Hibernate Validator now throws an exception in every case if trying to perform validation on a property or a method not present in a bean (before this version, no errors were thrown if the bean was totally unconstrained and an error was thrown when validating method parameters but not when validating return values). More generally, sanity checks on the various Validator#validate…​() methods parameters are now always applied, even if the bean is unconstrained.

The group id of Hibernate Validator has changed from org.hibernate to org.hibernate.validator. Refer to the artifacts via org.hibernate.validator:hibernate-validator:6.0.0.Final, org.hibernate.validator:hibernate-validator-cdi:6.0.0.Final and org.hibernate.validator:hibernate-validator-annotation-processor:6.0.0.Final, respectively.

Removal/change of experimental features in the favor of equivalent functionality standardized in Bean Validation 2.0:

We changed slightly the way the javax.el ExpressionFactory is initialized. Before this release, if you used a ResourceBundleMessageInterpolator, HV could be initialized with only a dependency to the javax.el API as the ExpressionFactory was not initialized at bootstrap (and it would have failed at message interpolation). As we now initialize the ExpressionFactory at bootstrap, if the ResourceBundleMessageInterpolator is used, you also need to have a javax.el implementation available. So, in the end, either you don’t use ResourceBundleMessageInterpolator at all and then you don’t need any javax.el dependency or you use a ResourceBundleMessageInterpolator and the javax.el API and an implementation are required by HV.

The (experimental) notion of ConstraintDefinitionContributor has been removed from the public API. Instead the new method ConstraintMapping#constraintDefinition() should be used when constraint definitions need to be added programmatically. This change makes the API for programmatic constraint definition and declaration consistent with the XML approach for achieving the same. The following elements have been removed:

The possibility to add constraint validators by means of the Java service loader mechanism (via a META-INF/services/javax.validation.ConstraintValidator file) remains in place.

The configuration option hibernate.validator.constraint_mapping_contributor has been deprecated in favor of hibernate.validator.constraint_mapping_contributors which accepts a comma separated list of contributors. The constant o.h.v.HibernateValidatorConfiguration#CONSTRAINT_MAPPING_CONTRIBUTOR has been deprecated in favor of o.h.v.HibernateValidatorConfiguration#CONSTRAINT_MAPPING_CONTRIBUTORS (HV-1065)

The @Mod10Check and @Mod11Check constraints introduced in 5.1.0.Beta1 got an overhaul. Indeces are now always inclusive (especially the endIndex) and are always relative to the validated value, independent of ignoreNonDigitCharacters. Also checkDigitPosition got renamed into checkDigitIndex.

The programmatic constraint declaration API raises a ValidationException now in case the same element (type, property, method etc.) is configured more than once within the mappings used to configure one validator factory. While this was possible before, it was not recommended as it may have caused issues when e.g. configuring conflicting annotation ignore options (HV-716). Instead select any element to be configured once and apply all required configurations subsequently.

When building Hibernate Validator from the sources yourself, you need to use now JDK 7 and Maven 3.0.3 or later. Note that the created binaries are still Java 6 compatible (HV-619, HV-797).

The Hibernate Validator CDI portable extension has been extracted from the main JAR into a separate module (HV-778). To make use of the extension, the dependency org.hibernate:hibernate-validator-cdi:5.0.0.CR5 must be added to the classpath.

@ValidateExecutable is reamed to @ValidateOnExecution and the ExecutableType.IMPLICIT is introduced - BVAL-437

MethodDescriptor#areParametersConstrained got renamed into MethodDescriptor#hasConstrainedParameters and MethodDescriptor#isReturnValueConstrained into MethodDescriptor#hasConstrainedReturnValue - BVAL-432

XML config element <validated-executables></validated> is renamed to <default-validated-executable-types></default> and matching BootstrapConfiguration#getValidatedExecutableTypes to BootstrapConfiguration#getDefaultValidatedExecutableTypes - BVAL-435

Methods of ParameterNameProvider interface return now List instead of String[] - BVAL-409

@CrossParameterConstraint got replaced by @SupportValidationTarget - BVAL-391

Renamed javax.validation.MethodValidator to ExecutableValidator; j.v.Validator#forMethods() renamed to forExecutables() (BVAL-355)

Made methods j.v.ExecutableValidator#validateConstructorParameters() and validateConstructorReturnValue() more usable (BVAL-358)

Deprecated org.hibernate.validator.messageinterpolation.ValueFormatterMessageInterpolator; the validated value can now be used within EL expressions (BVAL-223)

Removed annotation javax.validation.cdi.MethodValidated (BVAL-376)

Removed Maven archetype (HV-650)

This release requires Bean Validation 1.1.0.Beta2

Methods for method validation moved from javax.validation.Validator to MethodValidator (BVAL-310)

javax.validation.ConfigurationSource renamed to BootstrapConfiguration (BVAL-293)

Removed types deprecated in Hibernate Validator 4.3.0 (HV-584)

This release requires Bean Validaton 1.1 as a dependency (more concretely 1.1.0.Alpha1)

The custom method validation feature has been replaced by the method validation specfied by Bean Validation 1.1

The deprecated classes and methods from HV-561 have been removed. This means if you are using any of the affected APIs you will need to migrate

org.hibernate.validator.group.DefaultGroupSequenceProvider is deprecated and replaced by org.hibernate.validator.group.spi.DefaultGroupSequenceProvider

org.hibernate.validator.resourceloading.ResourceBundleLocator is deprecated and replaced by org.hibernate.validator.spi.resourceloading.ResourceBundleLocator

The constructor of org.hibernate.validator.cfg.ConstraintMapping is deprecated. Instances of ConstraintMapping are now created via HibernateValidatorConfiguration#createConstraintMapping()

The package org.hibernate.validator.method with its containing classes is deprecated without alternative for now. In Hibernate Validator 5 this package will be removed to align with Bean Validation 1.1. The method level validation methods will then be available via javax.validation.Validator.

org.hibernate.validator.internal.util.LazyValidatorFactory is deprecated and will be removed in HV 5