Deep Analysis of @Valid vs @Validated in Spring: From JSR-303 Standards to Validation Group Extensions

Technical Background and Standard Evolution of Validation Annotations

In the validation system of the Spring framework, @Valid and @Validated are two core annotations representing different technical standards and implementation paths. @Valid originates from the JSR-303 (Java Bean Validation) standard, belongs to the javax.validation package, and is part of the Java EE/Java SE specification. In contrast, @Validated is a proprietary extension by Spring, located in the org.springframework.validation.annotation package, designed to address limitations in the standard annotation's functionality.

Core Functional Difference: Support for Validation Groups

The most significant distinction is that @Validated supports validation groups, a feature absent in @Valid. Validation groups allow developers to categorize validation rules and apply different validation logic in various scenarios. For example, in a multi-step form, the first step might only require validating username and email, while the second step needs to validate password and confirmed password. Through validation groups, the validation scope for each step can be precisely controlled.

Here is a concrete implementation example of validation groups:

public class Account {
    
    public interface ValidationStepOne {}
    public interface ValidationStepTwo {}
    
    @NotBlank(groups = {ValidationStepOne.class})
    private String username;
    
    @Email(groups = {ValidationStepOne.class})
    @NotBlank(groups = {ValidationStepOne.class})
    private String email;
    
    @NotBlank(groups = {ValidationStepTwo.class})
    @StrongPassword(groups = {ValidationStepTwo.class})
    private String password;
    
    @NotBlank(groups = {ValidationStepTwo.class})
    private String confirmedPassword;
}

In the controller, it can be used as follows:

@RequestMapping(value = "stepOne")
public String stepOne(@Validated(Account.ValidationStepOne.class) Account account) {
    // Validates only fields in the ValidationStepOne group
}

@RequestMapping(value = "stepTwo")
public String stepTwo(@Validated(Account.ValidationStepTwo.class) Account account) {
    // Validates only fields in the ValidationStepTwo group
}

Technical Implementation and Standard Compatibility Analysis

@Valid, as a standard annotation, relies on underlying JSR-303 providers (e.g., Hibernate Validator) for implementation. Spring integrates it into the framework via LocalValidatorFactoryBean, ensuring compatibility with Java EE standards. @Validated, however, is Spring's extension of the validation mechanism. While designed to work synergistically with JSR-303, it is not entirely constrained by that standard.

From a source code perspective, the definition of the @Validated annotation includes a value() method for specifying validation groups:

@Target({ElementType.TYPE, ElementType.METHOD, ElementType.PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Validated {
    Class<?>[] value() default {};
}

This design allows Spring to offer more flexible validation strategies beyond standard validation. For instance, in Spring MVC, @Validated can be combined with MethodValidationPostProcessor to support method-level parameter validation.

Usage Scenarios and Best Practice Recommendations

For simple single-step form validation, @Valid is often the preferred choice due to its compliance with Java standards and higher code portability. For example:

@RequestMapping(value = "/createAccount")
public String createAccount(@Valid Account account, BindingResult result) {
    if (result.hasErrors()) {
        return "errorView";
    }
    // Processing logic
}

In the following scenarios, @Validated offers more advantages:

1. Multi-step form validation: Such as step-by-step validation in user registration processes.
2. Conditional validation: Enabling different validation rules based on various business rules.
3. Method-level validation: Validating parameters at the Service or Repository layer.

It is important to note that @Validated was introduced in Spring 3.1 and later, driven by community demand for more flexible validation mechanisms (as documented in Spring JIRA ticket SPR-6373). Due to the slower updates of the JSR-303 standard, the Spring team implemented validation group functionality early through @Validated, providing a transitional solution for developers.

Integration Considerations and Common Issues

In practical projects, both can be used together, but the following points should be noted:

• When both @Valid and @Validated are used, Spring prioritizes the validation groups specified by @Validated.
• If validation groups are not specified in @Validated, its behavior is similar to @Valid, validating all constraints.
• In Spring Boot projects, JSR-303 validation support is configured by default, allowing @Valid usage without additional setup. For method-level validation with @Validated, explicit configuration of MethodValidationPostProcessor is required.

A common mistake is forgetting to specify the groups attribute in constraint annotations when using validation groups, leading to validation rules not being executed. For example:

// Incorrect example: groups not specified
@NotBlank
private String username;

// Correct example: groups specified
@NotBlank(groups = {ValidationStepOne.class})
private String username;

Future Development and Technical Trends

With the release of JSR-380 (Bean Validation 2.0), standard validation capabilities have been enhanced, but the concept of validation groups remains unique to Spring's @Validated. In microservices architecture and Domain-Driven Design (DDD), the use cases for validation groups may expand further, such as applying different validation rules based on the context of different aggregates.

Developers should monitor Spring framework release notes for the latest improvements to @Validated functionality. For long-term projects, it is advisable to evaluate whether some @Validated features should be migrated to future JSR standard implementations to maintain standardization of the technology stack.