Jakarta Validation

Easier Custom Constraint Validator Integration: developers of custom constraints can now declare their ConstraintValidator implementations using the Java Service Loader mechanism. This decouples the constraint definition and the constraint validator implementation details. It especially simplifies the process for external libraries to add support for more types to constraints existing in other libraries, including the default, Jakarta Validation ones.

Optional validatedBy Attribute: The validatedBy attribute on the jakarta.validation.Constraint annotation is now optional. It defaults to an empty array, which cleans up the code when you don’t need to specify validators explicitly, for example, when you define your constraint validators through a service loader mechanism.

Simplified Attribute Retrieval: We’ve introduced a simpler, more direct way to fetch a single attribute from a ConstraintDescriptor. This reduces the boilerplate type casts.

Clarified Number Validation for Strings: Both @Min and @Max constraints were already able to validate the string representation of numbers, as the TCK was testing for it. Hence, from now on, it is explicitly mentioned that these constraints are applicable to Strings. This also better matches the behaviour of their decimal counterparts: @DecimalMin and @DecimalMax

Formal Deprecation of ConstraintViolationBuilder Methods: Some methods in the ConstraintViolationBuilder that were previously marked as deprecated only in the Javadoc comments are now formally deprecated. This makes it clearer which methods you should avoid using going forward and sets the stage for future removals.

We are planning to make it clear that after Jakarta Validation 4.0 the legacy approach to cascading validation will be removed.

@Valid // (1)
List<MyObject> legacyObjects;

List<@Valid MyObject> objects; // (2)

There is also a discussion on providing access to the initialization context within the constraint validator initialization step. Currently, ConstraintValidator#initialize(..) method only exposes the constraint annotation to the ConstraintValidator implementer. However, it may be useful for some constraints to obtain more information at this stage. For example, constraints dealing with temporal types may need to get their hand on the ClockProvider, or get access to some of the Jakarta Validation provider-specific details.

This version of the specification will require Java SE 21 or higher.

Prepare for removal of the legacy approach to mark container elements for cascading validation, i.e. @Valid List<MyBean> list;. The next major version will consider such code to be requesting the cascading validation of the List, and not its elements. It’s time to finally switch any remaining code using this approach to the much more encouraged and cleaner List<@Valid MyBean> list; If you have a particular use case where you think that you won’t be able to express your constraints without relying on the legacy approach — please reach out on the corresponding issue.

Introduce an alternative initialization method ConstraintValidator#initialize to provide more context than just the annotation so that it would be possible to use a more eager approach to initializing the constraint validator.

Relax element order in the XSD where it doesn’t matter.

Add support for ConstraintValidator declaration via service loader.

Remove any uses of the SecurityManager as it’s being deprecated without an alternative for some time now.

Reevaluate the value extraction for Optional and whether null should be passed as an extracted value for empty optionals.

Other more minor clarifications, cleanups and improvements.

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.

The Bean Validation 2.0 landing page

The Bean Validation 1.1 landing page