组

组的基本概念基本上没有改变，但它已经演变成一个更加类型安全且更简洁的生物。不再将组声明为字符串，现在组是接口。这有几个优点，包括

在IDE中更容易找到组的使用
由于拼写错误导致的错误将在编译时而不是运行时可见
组可以使用自然接口继承模型相互继承。这允许组合组。
根据包含约束定义的接口进行部分验证

/** 
 * Customer can buy bypassing the harassing checking process 
 * 
 * @author Emmanuel Bernard 
 */ 
public interface BuyInOneClick extends Default, Billable {} 

/** 
 * User representation 
 */ 
public class User { 
    @NotNull private String firstname; 
    @NotNull(groups = Default.class) private String lastname; 
    @NotNull(groups = {Billable.class}) private CreditCard defaultCreditCard; 
}

Set<ConstraintViolation> violations = validator.validate(user, BuyInOneClick.class);

规范易于阅读，并包含许多实际示例，请参阅第3.4节。

约束

约束现在可以声明性地由更原始的约束组成。这既有助于减少代码重复，也允许原始约束在元数据中公开，并用于JavaScript生成器等工具。

@Numerical
@Size(min=5, max=5)
@ConstraintValidator(FrenchZipcodeValidator.class)
@Documented
@Target({ANNOTATION_TYPE, METHOD, FIELD})
@Retention(RUNTIME)
public @interface FrenchZipCode {
    String message() default "Wrong zipcode";
    Class<?>[] groups() default {};
}

我在这篇之前的博客条目中更详细地描述了这一想法。

谈到约束定义，规范现在附带了一套内置约束@Null, @NotNull, @AssertTrue, @AssertFalse, @Min, @Max, @Size, @Digits, @Past, @Future。这些都是所有访问元数据的工具可以理解的基本块。

最后，约束实现现在可以针对每个约束生成多个违规报告。当针对两个特定属性进行操作的bean级别约束时，这一点特别有用。

@CheckAddressConsistency
public class Address {
  private String zipCode;
  private String city;
}

@CheckAddressConsistency可能希望生成两个违规报告，一个针对邮编另一个针对城市。根据失败情况定义细粒度错误消息也很有用。有关更多信息，请参阅第2.4节。

API

TheValidator接口现在可以验证任何类型的对象，不再局限于特定的JavaBean类型。

Validator validator = validatorFactory.getValidator();
Set<ConstraintViolation<Address>> addressViolations = validator.validate(address);
Set<ConstraintViolation<User>> userViolations = validator.validate(user);

规范提供了一个启动API，允许您自定义各种验证组件，并可选择选择您寻求的特定Bean Validation提供程序。旧版本的启动API在本博客条目中描述，最新版本当然可在规范第4.4节找到。

附录中，您将找到方法级验证的建议：参数和返回值可以用约束声明进行装饰。这一功能被广泛请求，让我们知道您的想法。