[[chapter-bean-constraints]] == Declaring and validating bean constraints In this chapter you will learn how to declare (see <>) and validate (see <>) bean constraints. <> provides an overview of all built-in constraints coming with Hibernate Validator. If you are interested in applying constraints to method parameters and return values, refer to <>. [[section-declaring-bean-constraints]] === Declaring bean constraints Constraints in Jakarta Validation are expressed via Java annotations. In this section you will learn how to enhance an object model with these annotations. There are four types of bean constraints: * field constraints * property constraints * container element constraints * class constraints [NOTE] ==== Not all constraints can be placed on all of these levels. In fact, none of the default constraints defined by Jakarta Validation can be placed at class level. The `java.lang.annotation.Target` annotation in the constraint annotation itself determines on which elements a constraint can be placed. See <> for more information. ==== ==== Field-level constraints Constraints can be expressed by annotating a field of a class. <> shows a field level configuration example: [[example-field-level]] .Field-level constraints ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/fieldlevel/Car.java[tags=include] ---- ==== When using field-level constraints field access strategy is used to access the value to be validated. This means the validation engine directly accesses the instance variable and does not invoke the property accessor method even if such an accessor exists. Constraints can be applied to fields of any access type (public, private etc.). Constraints on static fields are not supported, though. [TIP] ==== When validating byte code enhanced objects, property level constraints should be used, because the byte code enhancing library won't be able to determine a field access via reflection. ==== ==== Property-level constraints If your model class adheres to the http://www.oracle.com/technetwork/articles/javaee/spec-136004.html[JavaBeans] standard, it is also possible to annotate the properties of a bean class instead of its fields. <> uses the same entity as in <>, however, property level constraints are used. [[example-property-level]] .Property-level constraints ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/propertylevel/Car.java[tags=include] ---- ==== [NOTE] ==== The property's getter method has to be annotated, not its setter. That way also read-only properties can be constrained which have no setter method. ==== When using property level constraints property access strategy is used to access the value to be validated, i.e. the validation engine accesses the state via the property accessor method. [TIP] ==== It is recommended to stick either to field _or_ property annotations within one class. It is not recommended to annotate a field _and_ the accompanying getter method as this would cause the field to be validated twice. ==== [[container-element-constraints]] ==== Container element constraints It is possible to specify constraints directly on the type argument of a parameterized type: these constraints are called container element constraints. This requires that `ElementType.TYPE_USE` is specified via `@Target` in the constraint definition. As of Jakarta Bean Validation 2.0, built-in Jakarta Validation as well as Hibernate Validator specific constraints specify `ElementType.TYPE_USE` and can be used directly in this context. Hibernate Validator validates container element constraints specified on the following standard Java containers: * implementations of `java.util.Iterable` (e.g. ``List``s, ``Set``s), * implementations of `java.util.Map`, with support for keys and values, * `java.util.Optional`, `java.util.OptionalInt`, `java.util.OptionalDouble`, `java.util.OptionalLong`, * the various implementations of JavaFX's `javafx.beans.observable.ObservableValue`. It also supports container element constraints on custom container types (see <>). [NOTE] ==== In versions prior to 6, a subset of container element constraints were supported. A `@Valid` annotation was required at the container level to enable them. This is not required anymore as of Hibernate Validator 6. ==== We present below a couple of examples illustrating container element constraints on various Java types. In these examples, `@ValidPart` is a custom constraint allowed to be used in the `TYPE_USE` context. ===== With `Iterable` When applying constraints on an `Iterable` type argument, Hibernate Validator will validate each element. <> shows an example of a `Set` with a container element constraint. [[example-container-element-constraints-iterable]] .Container element constraint on `Set` ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/set/Car.java[tags=include] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/set/CarTest.java[tags=validateSetContainerElementConstraint] ---- ==== Note how the property path clearly states that the violation comes from an element of the iterable. ===== With `List` When applying constraints on a `List` type argument, Hibernate Validator will validate each element. <> shows an example of a `List` with a container element constraint. [[example-container-element-constraints-list]] .Container element constraint on `List` ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/list/Car.java[tags=include] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/list/CarTest.java[tags=validateListContainerElementConstraint] ---- ==== Here, the property path also contains the index of the invalid element. ===== With `Map` Container element constraints are also validated on map keys and values. <> shows an example of a `Map` with a constraint on the key and a constraint on the value. [[example-container-element-constraints-map]] .Container element constraint on map keys and values ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/map/Car.java[tags=include] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/map/CarTest.java[tags=validateMapValueContainerElementConstraint] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/map/CarTest.java[tags=validateMapKeyContainerElementConstraint] ---- ==== The property paths of the violations are particularly interesting: * The key of the invalid element is included in the property path (in the second example, the key is `null`). * In the first example, the violation concerns the ``, in the second one, the ``. * In the second example, you might have noticed the presence of the type argument ``, more on this later. ===== With `java.util.Optional` When applying a constraint on the type argument of `Optional`, Hibernate Validator will automatically unwrap the type and validate the internal value. <> shows an example of an `Optional` with a container element constraint. [[example-container-element-constraints-optional]] .Container element constraint on Optional ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/optional/Car.java[tags=include] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/optional/CarTest.java[tags=validateOptionalContainerElementConstraint] ---- ==== Here, the property path only contains the name of the property as we are considering `Optional` as a "transparent" container. ===== With custom container types Container element constraints can also be used with custom containers. A `ValueExtractor` must be registered for the custom type allowing to retrieve the value(s) to validate (see <> for more information about how to implement your own `ValueExtractor` and how to register it). <> shows an example of a custom parameterized type with a type argument constraint. [[example-container-element-constraints-custom-container-type]] .Container element constraint on custom container type ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/custom/Car.java[tags=include] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/custom/GearBox.java[tags=include] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/custom/Gear.java[tags=include] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/custom/GearBoxValueExtractor.java[tags=include] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/custom/CarTest.java[tags=validateCustomContainerElementConstraint] ---- ==== ===== Nested container elements Constraints are also supported on nested container elements. When validating a `Car` object as presented in <>, both the `@NotNull` constraints on `Part` and `Manufacturer` will be enforced. [[example-container-element-nested]] .Constraints on nested container elements ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/containerelement/nested/Car.java[tags=include] ---- ==== [[validator-usingvalidator-classlevel]] ==== Class-level constraints Last but not least, a constraint can also be placed on the class level. In this case not a single property is subject of the validation but the complete object. Class-level constraints are useful if the validation depends on a correlation between several properties of an object. The `Car` class in <> has the two attributes `seatCount` and `passengers` and it should be ensured that the list of passengers does not have more entries than available seats. For that purpose the `@ValidPassengerCount` constraint is added on the class level. The validator of that constraint has access to the complete `Car` object, allowing to compare the numbers of seats and passengers. Refer to <> to learn in detail how to implement this custom constraint. [[example-class-level]] .Class-level constraint ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/classlevel/Car.java[tags=include] ---- ==== [[section-constraint-inheritance]] ==== Constraint inheritance When a class implements an interface or extends another class, all constraint annotations declared on the super-type apply in the same manner as the constraints specified on the class itself. To make things clearer let's have a look at the following example: .Constraint inheritance ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/inheritance/Car.java[tags=include] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/inheritance/RentalCar.java[tags=include] ---- ==== Here the class `RentalCar` is a subclass of `Car` and adds the property `rentalStation`. If an instance of `RentalCar` is validated, not only the `@NotNull` constraint on `rentalStation` is evaluated, but also the constraint on `manufacturer` from the parent class. The same would be true, if `Car` was not a superclass but an interface implemented by `RentalCar`. Constraint annotations are aggregated if methods are overridden. So if `RentalCar` overrode the `getManufacturer()` method from `Car`, any constraints annotated at the overriding method would be evaluated in addition to the `@NotNull` constraint from the superclass. [[section-object-graph-validation]] ==== Object graphs The Jakarta Validation API does not only allow to validate single class instances but also complete object graphs (cascaded validation). To do so, just annotate a field or property representing a reference to another object with `@Valid` as demonstrated in <>. [[example-cascaded-validation]] .Cascaded validation ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/objectgraph/Car.java[tags=include] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/objectgraph/Person.java[tags=include] ---- ==== If an instance of `Car` is validated, the referenced `Person` object will be validated as well, as the `driver` field is annotated with `@Valid`. Therefore the validation of a `Car` will fail if the `name` field of the referenced `Person` instance is `null`. The validation of object graphs is recursive, i.e. if a reference marked for cascaded validation points to an object which itself has properties annotated with `@Valid`, these references will be followed up by the validation engine as well. The validation engine will ensure that no infinite loops occur during cascaded validation, for example if two objects hold references to each other. Note that `null` values are getting ignored during cascaded validation. As constraints, object graph validation also works for container elements. That means any type argument of a container can be annotated with `@Valid`, which will cause each contained element to be validated when the parent object is validated. [NOTE] ==== Cascaded validation is also supported for nested container elements. ==== [[example-cascaded-validation-list]] .Cascaded validation of containers ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/objectgraph/containerelement/Car.java[tags=include] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/objectgraph/containerelement/Part.java[tags=include] ---- [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/objectgraph/containerelement/Manufacturer.java[tags=include] ---- ==== When validating an instance of the `Car` class shown in <>, a `ConstraintViolation` will be created: * if any of the `Person` objects contained in the passengers list has a `null` name; * if any of the `Part` objects contained in the map keys has a `null` name; * if any of the `Manufacturer` objects contained in the list nested in the map values has a `null` name. [NOTE] ==== In versions prior to 6, Hibernate Validator supported cascaded validation for a subset of container elements and it was implemented at the container level (e.g. you would use `@Valid private List` to enable cascaded validation for `Person`). This is still supported but is not recommended. Please use container element level `@Valid` annotations instead as it is more expressive. ==== [[section-validating-bean-constraints]] === Validating bean constraints The `Validator` interface is the most important object in Jakarta Validation. The next section shows how to obtain a `Validator` instance. Afterwards you'll learn how to use the different methods of the `Validator` interface. [[section-obtaining-validator]] ==== Obtaining a `Validator` instance The first step towards validating an entity instance is to get hold of a `Validator` instance. The road to this instance leads via the `Validation` class and a `ValidatorFactory`. The easiest way is to use the static method `Validation#buildDefaultValidatorFactory()`: .`Validation#buildDefaultValidatorFactory()` ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/validation/ValidationTest.java[tags=setUpValidator] ---- ==== This bootstraps a validator in the default configuration. Refer to <> to learn more about the different bootstrapping methods and how to obtain a specifically configured `Validator` instance. ==== Validator methods The `Validator` interface contains three methods that can be used to either validate entire entities or just single properties of the entity. All three methods return a `Set`. The set is empty, if the validation succeeds. Otherwise a `ConstraintViolation` instance is added for each violated constraint. All the validation methods have a var-args parameter which can be used to specify which validation groups shall be considered when performing the validation. If the parameter is not specified, the default validation group (`jakarta.validation.groups.Default`) is used. The topic of validation groups is discussed in detail in <>. ===== `Validator#validate()` Use the `validate()` method to perform validation of all constraints of a given bean. <> shows the validation of an instance of the `Car` class from <> which fails to satisfy the `@NotNull` constraint on the `manufacturer` property. The validation call therefore returns one `ConstraintViolation` object. [[example-validator-validate]] .Using `Validator#validate()` ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/validation/ValidationTest.java[tags=validate] ---- ==== ===== `Validator#validateProperty()` With help of the `validateProperty()` you can validate a single named property of a given object. The property name is the JavaBeans property name. .Using `Validator#validateProperty()` ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/validation/ValidationTest.java[tags=validateProperty] ---- ==== ===== `Validator#validateValue()` By using the `validateValue()` method you can check whether a single property of a given class can be validated successfully, if the property had the specified value: .Using `Validator#validateValue()` ==== [source, JAVA, indent=0] ---- include::{sourcedir}/org/hibernate/validator/referenceguide/chapter02/validation/ValidationTest.java[tags=validateValue] ---- ==== [NOTE] ==== `@Valid` is not honored by `validateProperty()` or `validateValue()`. ==== `Validator#validateProperty()` is for example used in the integration of Jakarta Validation into JSF 2 (see <>) to perform a validation of the values entered into a form before they are propagated to the model. [[section-constraint-violation-methods]] ==== `ConstraintViolation` ===== `ConstraintViolation` methods Now it is time to have a closer look at what a `ConstraintViolation` is. Using the different methods of `ConstraintViolation` a lot of useful information about the cause of the validation failure can be determined. The following gives an overview of these methods. The values under "Example" column refer to <>. `getMessage()`:: The interpolated error message Example::: "must not be null" `getMessageTemplate()`:: The non-interpolated error message Example::: "{... NotNull.message}" `getRootBean()`:: The root bean being validated Example::: car `getRootBeanClass()`:: The class of the root bean being validated Example::: `Car.class` `getLeafBean()`:: If a bean constraint, the bean instance the constraint is applied on; if a property constraint, the bean instance hosting the property the constraint is applied on Example::: `car` `getPropertyPath()`:: The property path to the validated value from root bean Example::: contains one node with kind `PROPERTY` and name "manufacturer" `getInvalidValue()`:: The value failing to pass the constraint Example::: `null` `getConstraintDescriptor()`:: Constraint metadata reported to fail Example::: descriptor for `@NotNull` ===== Exploiting the property path To determine the element that triggered the violation, you need to exploit the result of the `getPropertyPath()` method. The returned `Path` is composed of ``Node``s describing the path to the element. More information about the structure of the `Path` and the various types of ``Node``s can be found in {bvSpecUrl}#validationapi-constraintviolation[the `ConstraintViolation` section] of the Jakarta Validation specification. [[section-builtin-constraints]] === Built-in constraints Hibernate Validator comprises a basic set of commonly used constraints. These are foremost the constraints defined by the Jakarta Validation specification (see <>). Additionally, Hibernate Validator provides useful custom constraints (see <>). [[validator-defineconstraints-spec]] ==== Jakarta Validation constraints Below you can find a list of all constraints specified in the Jakarta Validation API. All these constraints apply to the field/property level, there are no class-level constraints defined in the Jakarta Validation specification. If you are using the Hibernate object-relational mapper, some of the constraints are taken into account when creating the DDL for your model (see "Hibernate metadata impact"). [NOTE] ==== Hibernate Validator allows some constraints to be applied to more data types than required by the Jakarta Validation specification (e.g. `@Max` can be applied to strings). Relying on this feature can impact portability of your application between Jakarta Validation providers. ==== `@AssertFalse`:: Checks that the annotated element is false Supported data types::: `Boolean`, `boolean` Hibernate metadata impact::: None `@AssertTrue`:: Checks that the annotated element is true Supported data types::: `Boolean`, `boolean` Hibernate metadata impact::: None `@DecimalMax(value=, inclusive=)`:: Checks whether the annotated value is less than the specified maximum, when `inclusive`=false. Otherwise whether the value is less than or equal to the specified maximum. The parameter value is the string representation of the max value according to the `BigDecimal` string representation. Supported data types::: `BigDecimal`, `BigInteger`, `CharSequence`, `byte`, `short`, `int`, `long` and the respective wrappers of the primitive types; additionally supported by HV: any sub-type of `Number` and `javax.money.MonetaryAmount` (if the https://jcp.org/en/jsr/detail?id=354[JSR 354 API] and an implementation is on the class path) Hibernate metadata impact::: None `@DecimalMin(value=, inclusive=)`:: Checks whether the annotated value is larger than the specified minimum, when `inclusive`=false. Otherwise whether the value is larger than or equal to the specified minimum. The parameter value is the string representation of the min value according to the `BigDecimal` string representation. Supported data types::: `BigDecimal`, `BigInteger`, `CharSequence`, `byte`, `short`, `int`, `long` and the respective wrappers of the primitive types; additionally supported by HV: any sub-type of `Number` and `javax.money.MonetaryAmount` Hibernate metadata impact::: None `@Digits(integer=, fraction=)`:: Checks whether the annotated value is a number having up to `integer` digits and `fraction` fractional digits Supported data types::: BigDecimal, `BigInteger`, `CharSequence`, `byte`, `short`, `int`, `long` and the respective wrappers of the primitive types; additionally supported by HV: any sub-type of `Number` and `javax.money.MonetaryAmount` Hibernate metadata impact::: Defines column precision and scale `@Email`:: Checks whether the specified character sequence is a valid email address. The optional parameters `regexp` and `flags` allow to specify an additional regular expression (including regular expression flags) which the email must match. Supported data types::: `CharSequence` Hibernate metadata impact::: None `@Future`:: Checks whether the annotated date is in the future Supported data types::: `java.util.Date`, `java.util.Calendar`, `java.time.Instant`, `java.time.LocalDate`, `java.time.LocalDateTime`, `java.time.LocalTime`, `java.time.MonthDay`, `java.time.OffsetDateTime`, `java.time.OffsetTime`, `java.time.Year`, `java.time.YearMonth`, `java.time.ZonedDateTime`, `java.time.chrono.HijrahDate`, `java.time.chrono.JapaneseDate`, `java.time.chrono.MinguoDate`, `java.time.chrono.ThaiBuddhistDate`; additionally supported by HV, if the http://www.joda.org/joda-time/[Joda Time] date/time API is on the classpath: any implementations of `ReadablePartial` and `ReadableInstant` Hibernate metadata impact::: None `@FutureOrPresent`:: Checks whether the annotated date is in the present or in the future Supported data types::: `java.util.Date`, `java.util.Calendar`, `java.time.Instant`, `java.time.LocalDate`, `java.time.LocalDateTime`, `java.time.LocalTime`, `java.time.MonthDay`, `java.time.OffsetDateTime`, `java.time.OffsetTime`, `java.time.Year`, `java.time.YearMonth`, `java.time.ZonedDateTime`, `java.time.chrono.HijrahDate`, `java.time.chrono.JapaneseDate`, `java.time.chrono.MinguoDate`, `java.time.chrono.ThaiBuddhistDate`; additionally supported by HV, if the http://www.joda.org/joda-time/[Joda Time] date/time API is on the classpath: any implementations of `ReadablePartial` and `ReadableInstant` Hibernate metadata impact::: None `@Max(value=)`:: Checks whether the annotated value is less than or equal to the specified maximum Supported data types::: `BigDecimal`, `BigInteger`, `byte`, `short`, `int`, `long` and the respective wrappers of the primitive types; additionally supported by HV: any sub-type of `CharSequence` (the numeric value represented by the character sequence is evaluated), any sub-type of `Number` and `javax.money.MonetaryAmount` Hibernate metadata impact::: Adds a check constraint on the column `@Min(value=)`:: Checks whether the annotated value is higher than or equal to the specified minimum Supported data types::: `BigDecimal`, `BigInteger`, `byte`, `short`, `int`, `long` and the respective wrappers of the primitive types; additionally supported by HV: any sub-type of `CharSequence` (the numeric value represented by the character sequence is evaluated), any sub-type of `Number` and `javax.money.MonetaryAmount` Hibernate metadata impact::: Adds a check constraint on the column `@NotBlank`:: Checks that the annotated character sequence is not null and the trimmed length is greater than 0. The difference to `@NotEmpty` is that this constraint can only be applied on character sequences and that trailing white-spaces are ignored. Supported data types::: `CharSequence` Hibernate metadata impact::: None `@NotEmpty`:: Checks whether the annotated element is not null nor empty Supported data types::: `CharSequence`, `Collection`, `Map` and arrays Hibernate metadata impact::: None `@NotNull`:: Checks that the annotated value is not `null` Supported data types::: Any type Hibernate metadata impact::: Column(s) are not nullable `@Negative`:: Checks if the element is strictly negative. Zero values are considered invalid. Supported data types::: `BigDecimal`, `BigInteger`, `byte`, `short`, `int`, `long` and the respective wrappers of the primitive types; additionally supported by HV: any sub-type of `CharSequence` (the numeric value represented by the character sequence is evaluated), any sub-type of `Number` and `javax.money.MonetaryAmount` Hibernate metadata impact::: None `@NegativeOrZero`:: Checks if the element is negative or zero. Supported data types::: `BigDecimal`, `BigInteger`, `byte`, `short`, `int`, `long` and the respective wrappers of the primitive types; additionally supported by HV: any sub-type of `CharSequence` (the numeric value represented by the character sequence is evaluated), any sub-type of `Number` and `javax.money.MonetaryAmount` Hibernate metadata impact::: None `@Null`:: Checks that the annotated value is `null` Supported data types::: Any type Hibernate metadata impact::: None `@Past`:: Checks whether the annotated date is in the past Supported data types::: `java.util.Date`,`java.util.Calendar`, `java.time.Instant`, `java.time.LocalDate`, `java.time.LocalDateTime`, `java.time.LocalTime`, `java.time.MonthDay`, `java.time.OffsetDateTime`, `java.time.OffsetTime`, `java.time.Year`, `java.time.YearMonth`, `java.time.ZonedDateTime`, `java.time.chrono.HijrahDate`, `java.time.chrono.JapaneseDate`, `java.time.chrono.MinguoDate`, `java.time.chrono.ThaiBuddhistDate`; Additionally supported by HV, if the http://www.joda.org/joda-time/[Joda Time] date/time API is on the classpath: any implementations of `ReadablePartial` and `ReadableInstant` Hibernate metadata impact::: None `@PastOrPresent`:: Checks whether the annotated date is in the past or in the present Supported data types::: `java.util.Date`,`java.util.Calendar`, `java.time.Instant`, `java.time.LocalDate`, `java.time.LocalDateTime`, `java.time.LocalTime`, `java.time.MonthDay`, `java.time.OffsetDateTime`, `java.time.OffsetTime`, `java.time.Year`, `java.time.YearMonth`, `java.time.ZonedDateTime`, `java.time.chrono.HijrahDate`, `java.time.chrono.JapaneseDate`, `java.time.chrono.MinguoDate`, `java.time.chrono.ThaiBuddhistDate`; Additionally supported by HV, if the http://www.joda.org/joda-time/[Joda Time] date/time API is on the classpath: any implementations of `ReadablePartial` and `ReadableInstant` Hibernate metadata impact::: None `@Pattern(regex=, flags=)`:: Checks if the annotated string matches the regular expression `regex` considering the given flag `match` Supported data types::: `CharSequence` Hibernate metadata impact::: None `@Positive`:: Checks if the element is strictly positive. Zero values are considered invalid. Supported data types::: `BigDecimal`, `BigInteger`, `byte`, `short`, `int`, `long` and the respective wrappers of the primitive types; additionally supported by HV: any sub-type of `CharSequence` (the numeric value represented by the character sequence is evaluated), any sub-type of `Number` and `javax.money.MonetaryAmount` Hibernate metadata impact::: None `@PositiveOrZero`:: Checks if the element is positive or zero. Supported data types::: `BigDecimal`, `BigInteger`, `byte`, `short`, `int`, `long` and the respective wrappers of the primitive types; additionally supported by HV: any sub-type of `CharSequence` (the numeric value represented by the character sequence is evaluated), any sub-type of `Number` and `javax.money.MonetaryAmount` Hibernate metadata impact::: None `@Size(min=, max=)`:: Checks if the annotated element's size is between `min` and `max` (inclusive) Supported data types::: `CharSequence`, `Collection`, `Map` and arrays Hibernate metadata impact::: Column length will be set to `max` [NOTE] ==== On top of the parameters listed above each constraint has the parameters message, groups and payload. This is a requirement of the Jakarta Validation specification. ==== [[validator-defineconstraints-hv-constraints]] ==== Additional constraints In addition to the constraints defined by the Jakarta Validation API, Hibernate Validator provides several useful custom constraints which are listed below. With one exception also these constraints apply to the field/property level, only `@ScriptAssert` is a class-level constraint. `@CreditCardNumber(ignoreNonDigitCharacters=)`:: Checks that the annotated character sequence passes the Luhn checksum test. Note, this validation aims to check for user mistakes, not credit card validity! See also http://www.dirigodev.com/blog/ecommerce/anatomy-of-a-credit-card-number/[Anatomy of a credit card number]. `ignoreNonDigitCharacters` allows to ignore non digit characters. The default is `false`. Supported data types::: `CharSequence` Hibernate metadata impact::: None `@Currency(value=)`:: Checks that the currency unit of the annotated `javax.money.MonetaryAmount` is part of the specified currency units. Supported data types::: any sub-type of `javax.money.MonetaryAmount` (if the https://jcp.org/en/jsr/detail?id=354[JSR 354 API] and an implementation is on the class path) Hibernate metadata impact::: None `@DurationMax(days=, hours=, minutes=, seconds=, millis=, nanos=, inclusive=)`:: Checks that annotated `java.time.Duration` element is not greater than the one constructed from annotation parameters. Equality is allowed if `inclusive` flag is set to `true`. Supported data types::: `java.time.Duration` Hibernate metadata impact::: None `@DurationMin(days=, hours=, minutes=, seconds=, millis=, nanos=, inclusive=)`:: Checks that annotated `java.time.Duration` element is not less than the one constructed from annotation parameters. Equality is allowed if `inclusive` flag is set to `true`. Supported data types::: `java.time.Duration` Hibernate metadata impact::: None `@EAN`:: Checks that the annotated character sequence is a valid http://en.wikipedia.org/wiki/International_Article_Number_%28EAN%29[EAN] barcode. type determines the type of barcode. The default is EAN-13. Supported data types::: `CharSequence` Hibernate metadata impact::: None `@ISBN`:: Checks that the annotated character sequence is a valid https://en.wikipedia.org/wiki/International_Standard_Book_Number[ISBN]. `type` determines the type of ISBN. The default is ISBN-13. Supported data types::: `CharSequence` Hibernate metadata impact::: None `@Length(min=, max=)`:: Validates that the annotated character sequence is between `min` and `max` included Supported data types::: `CharSequence` Hibernate metadata impact::: Column length will be set to max `@CodePointLength(min=, max=, normalizationStrategy=)`:: Validates that code point length of the annotated character sequence is between `min` and `max` included. Validates normalized value if `normalizationStrategy` is set. Supported data types::: `CharSequence` Hibernate metadata impact::: None `@LuhnCheck(startIndex= , endIndex=, checkDigitIndex=, ignoreNonDigitCharacters=)`:: Checks that the digits within the annotated character sequence pass the Luhn checksum algorithm (see also http://en.wikipedia.org/wiki/Luhn_algorithm[Luhn algorithm]). `startIndex` and `endIndex` allow to only run the algorithm on the specified sub-string. `checkDigitIndex` allows to use an arbitrary digit within the character sequence as the check digit. If not specified it is assumed that the check digit is part of the specified range. Last but not least, `ignoreNonDigitCharacters` allows to ignore non digit characters. Supported data types::: `CharSequence` Hibernate metadata impact::: None `@Mod10Check(multiplier=, weight=, startIndex=, endIndex=, checkDigitIndex=, ignoreNonDigitCharacters=)`:: Checks that the digits within the annotated character sequence pass the generic mod 10 checksum algorithm. `multiplier` determines the multiplier for odd numbers (defaults to 3), `weight` the weight for even numbers (defaults to 1). `startIndex` and `endIndex` allow to only run the algorithm on the specified sub-string. `checkDigitIndex` allows to use an arbitrary digit within the character sequence as the check digit. If not specified it is assumed that the check digit is part of the specified range. Last but not least, `ignoreNonDigitCharacters` allows to ignore non digit characters. Supported data types::: `CharSequence` Hibernate metadata impact::: None `@Mod11Check(threshold=, startIndex=, endIndex=, checkDigitIndex=, ignoreNonDigitCharacters=, treatCheck10As=, treatCheck11As=)`:: Checks that the digits within the annotated character sequence pass the mod 11 checksum algorithm. `threshold` specifies the threshold for the mod11 multiplier growth; if no value is specified the multiplier will grow indefinitely. `treatCheck10As` and `treatCheck11As` specify the check digits to be used when the mod 11 checksum equals 10 or 11, respectively. Default to X and 0, respectively. `startIndex`, `endIndex` `checkDigitIndex` and `ignoreNonDigitCharacters` carry the same semantics as in `@Mod10Check`. Supported data types::: `CharSequence` Hibernate metadata impact::: None `@Normalized(form=)`:: Validates that the annotated character sequence is normalized according to the given `form`. Supported data types::: `CharSequence` Hibernate metadata impact::: None `@Range(min=, max=)`:: Checks whether the annotated value lies between (inclusive) the specified minimum and maximum Supported data types::: `BigDecimal`, `BigInteger`, `CharSequence`, `byte`, `short`, `int`, `long` and the respective wrappers of the primitive types Hibernate metadata impact::: None `@ScriptAssert(lang=, script=, alias=, reportOn=)`:: Checks whether the given script can successfully be evaluated against the annotated element. In order to use this constraint, an implementation of the Java Scripting API as defined by JSR 223 ("Scripting for the Java^TM^ Platform") must be a part of the class path. The expressions to be evaluated can be written in any scripting or expression language, for which a JSR 223 compatible engine can be found in the class path. Even though this is a class-level constraint, one can use the `reportOn` attribute to report a constraint violation on a specific property rather than the whole object. Supported data types::: Any type Hibernate metadata impact::: None `@UniqueElements`:: Checks that the annotated collection only contains unique elements. The equality is determined using the `equals()` method. The default message does not include the list of duplicate elements but you can include it by overriding the message and using the `{duplicates}` message parameter. The list of duplicate elements is also included in the dynamic payload of the constraint violation. Supported data types::: `Collection` Hibernate metadata impact::: None `@URL(protocol=, host=, port=, regexp=, flags=)`:: Checks if the annotated character sequence is a valid URL according to RFC2396. If any of the optional parameters `protocol`, `host` or `port` are specified, the corresponding URL fragments must match the specified values. The optional parameters `regexp` and `flags` allow to specify an additional regular expression (including regular expression flags) which the URL must match. Per default this constraint used the `java.net.URL` constructor to verify whether a given string represents a valid URL. A regular expression based version is also available - `RegexpURLValidator` - which can be configured via XML (see <>) or the programmatic API (see <>). Supported data types::: `CharSequence` Hibernate metadata impact::: None `@UUID(allowEmpty=, allowNil=, version=, variant=, letterCase=)`:: Checks that the annotated character sequence is a valid universally unique identifier according to RFC 4122. `null` is always valid. The option `allowEmpty` allows empty character sequences. `allowNil` includes nil UUIDs (`00000000-0000-0000-0000-000000000000`). The `version` and `variant` parameters control which UUID versions and variants are allowed. `letterCase` ensures lower case or upper case, but can also be configured as case insensitive. Supported data types::: `CharSequence` Hibernate metadata impact::: None `@BitcoinAddress(value=)`:: Checks that the annotated character sequence is a valid Bitcoin address. `null` values are considered valid. The option `value` allows to specify which types of Bitcoin addresses should be considered as valid. By default, all address types are considered as valid. See `BitcoinAddress.BitcoinAddressType` for a list of available address types. Supported data types::: `CharSequence` Hibernate metadata impact::: None ===== Country specific constraints Hibernate Validator offers also some country specific constraints, e.g. for the validation of social security numbers. [NOTE] ==== If you have to implement a country specific constraint, consider making it a contribution to Hibernate Validator! ==== `@CNPJ`:: Checks that the annotated character sequence represents a Brazilian corporate tax payer registry number (Cadastro de Pessoa Jurídica). An optional `format` parameter allows picking which format of CNPJ should be considered valid `NUMERIC`, the current format, or `ALPHANUMERIC`, the one that will replace the current one starting January 2026. Supported data types::: `CharSequence` Hibernate metadata impact::: None Country::: Brazil `@CPF`:: Checks that the annotated character sequence represents a Brazilian individual taxpayer registry number (Cadastro de Pessoa Física) Supported data types::: `CharSequence` Hibernate metadata impact::: None Country::: Brazil `@TituloEleitoral`:: Checks that the annotated character sequence represents a Brazilian voter ID card number (http://www.exceldoseujeito.com.br/2008/12/19/validar-cpf-cnpj-e-titulo-de-eleitor-parte-ii/[Título Eleitoral]) Supported data types::: `CharSequence` Hibernate metadata impact::: None Country::: Brazil `@NIP`:: Checks that the annotated character sequence represents a Polish VAT identification number (https://pl.wikipedia.org/wiki/NIP[NIP]) Supported data types::: `CharSequence` Hibernate metadata impact::: None Country::: Poland `@PESEL`:: Checks that the annotated character sequence represents a Polish national identification number (https://pl.wikipedia.org/wiki/PESEL[PESEL]) Supported data types::: `CharSequence` Hibernate metadata impact::: None Country::: Poland `@REGON`:: Checks that the annotated character sequence represents a Polish taxpayer identification number (https://pl.wikipedia.org/wiki/REGON[REGON]). Can be applied to both 9 and 14 digits versions of REGON Supported data types::: `CharSequence` Hibernate metadata impact::: None Country::: Poland `@INN`:: Checks that the annotated character sequence represents a Russian taxpayer identification number (https://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B9_%D0%BD%D0%BE%D0%BC%D0%B5%D1%80_%D0%BD%D0%B0%D0%BB%D0%BE%D0%B3%D0%BE%D0%BF%D0%BB%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%89%D0%B8%D0%BA%D0%B0[INN]). Can be applied to both individual and juridical versions of INN Supported data types::: `CharSequence` Hibernate metadata impact::: None Country::: Russia `@KorRRN`:: Checks that the annotated character sequence represents a Korean resident registration number (https://ko.wikipedia.org/wiki/%EC%A3%BC%EB%AF%BC%EB%93%B1%EB%A1%9D%EB%B2%88%ED%98%B8[KorRRN]) Supported data types::: `CharSequence` Hibernate metadata impact::: None Country::: South Korea [TIP] ==== In some cases neither the Jakarta Validation constraints nor the custom constraints provided by Hibernate Validator will fulfill your requirements. In this case you can easily write your own constraint. You can find more information in <>. ====