相关内容

返回首页

支持Java 8的Hibernate Validator 5.2.0.Alpha1及5.1维护版本

发布者：    |       Bean Validation Hibernate Validator

经过一段时间的开发，我们很高兴地宣布Hibernate Validator 5.2系列的第一版发布 - 5.2.0.Alpha1。本版本主要关注Java 8的支持，但这将在下面详细说明。

首先，向Khalid Alqinyah表示衷心的感谢，作为Google Summer of Code项目的一部分，他实现了许多这些新功能。

那么，这对你有什么好处呢？

Java 8支持

注意：Java 8不是Hibernate Validator 5.2的要求。Hibernate Validator仍然与Java 6向后兼容。只有检测到Java 8运行时，Java 8特定功能才会启用。

首先，支持Java 8的日期/时间数据类型（JSR 310），可以通过以下方式验证：@Past和@Future。此外Optional和JavaFX类型可以通过改进的ValidatedValueUnwrapper进行支持。 ValidatedValueUnwrapper 已在Validator 5.1中引入，但现在工作方式更加透明。在验证时，将检查所有已注册的ValidatedValueUnwrapper实例。如果处理程序支持验证类型，则调用其handleValidatedValue方法，前提是存在没有匹配的ConstraintValidator为包装器本身。这最好用一个例子来说明

@Size(min = 3) // the @Size constraint can only apply to the string value which gets automatically validated
private Optional<String> firstName = Optional.of( "John" );

@NotNull
@UnwrapValidatedValue(false) // Use @UnwrapValidatedValue(false) to ensure the wrapper itself is validated
private Optional<String> lastName = Optional.of( "Doe" );
另一个与Java 8相关的功能是能够在Iterable实例上使用类型注解。例如：
private List<@AcmeEmail String> emails;
注意，此示例没有使用Hibernate Validator的@Email。既不能使用Bean Validation的内置约束，也不能使用Hibernate Validator特定的约束。简单的原因是，这些约束缺失java.lang.annotation.ElementType.TYPE_USE在其定义中，并且不能以向后兼容的方式添加。目前我们还没有决定要做什么。我们应该要求Validator 5.2使用Java 8，还是以某种方式提供JVM特定工件？您觉得呢？目前我们希望保持选项开放，看看Bean Validation 1.2和其他Java EE 8标准会走哪条路。目前，此功能仅限于自定义约束，您可以添加所需的ElementType自行。

最后但同样重要的是，在Java 8驱动的功能列表中，是ReflectionParameterNameProvider。这个新的ParameterNameProvider利用Java 8反射API的增强功能，并报告实际参数名，而不是通用的arg0、arg1等。此提供者正常工作的要求是源代码使用带有-parameters编译器选项编译。请参阅文档了解如何配置自定义ParameterNameProvider.

还有什么吗？

以下是本版本的一些亮点

ConstraintDefinitionContributor和constraint定义的ServiceLoader

Bean Bean Validation规范允许通过XML映射文件注册新的约束定义。例如

<constraint-definition annotation="org.hibernate.validator.constraints.URL">
  <validated-by include-existing-validators="false">
    <value>org.hibernate.validator.constraintvalidators.RegexpURLValidator</value>
  </validated-by>
</constraint-definition>

我们现在提供了两种贡献约束定义的方法。第一种是通过ConstraintDefinitionContributorSPI进行程序化。上面的例子看起来像这样

HibernateValidatorConfiguration configuration = Validation
        .byProvider( HibernateValidator.class )
        .configure();

configuration.addConstraintDefinitionContributor(
        new ConstraintDefinitionContributor() {
                @Override
                public void collectConstraintDefinitions(ConstraintDefinitionBuilder builder) {
                        builder.constraint( URL.class )
                                .includeExistingValidators( false )
                                .validatedBy( RegexpURLValidator.class );
                }
        }
);

顺便说一句，org.hibernate.validator.constraintvalidators.RegexpURLValidator不是一个虚构的类。这是另一个新特性（HV-920），它允许为@URL约束配置基于正则表达式的验证器。@URL约束。

回到约束定义。贡献约束定义的第二种方式是通过Java ServiceLoader机制。只需将META-INF/services/javax.validation.ConstraintValidator添加到您的工件清单中，列出您约束验证器类的完全限定名（每行一个）。此机制适用于添加新类型的约束定义。您不能像在XML中或通过ConstraintDefinitionContributor禁用默认定义。

ParameterMessageInterpolator

Hibernate Validator默认要求提供Unified EL的实现。对于无法或不想提供EL实现的运行环境，我们现在提供了一个基于非EL的消息插值器——org.hibernate.validator.messageinterpolation.ParameterMessageInterpolator.

警告：包含EL表达式的约束消息将返回未插值的！

这只是亮点。总共解决了40个问题。成为早期采用者之一，并从JBoss Maven仓库（GAV org.hibernate:hibernate-validator:5.2.Alpha1）或SourceForge发行版中获取Maven工件。

与5.2 alpha版本同时发布的是5.1维护版本。我们意外地在5.1.2.Final中破坏了Java 6的向后兼容性，因为我们使用了Collections#emptyIterator()。这在5.1.3.Final中得到了纠正，并且恢复了Java 6的兼容性。

5.1.3.Final中修复的第二个错误是HV-930，当Hibernate Validator的内部弱引用缓存因内存压力部分无效时，约束不会进行验证。

完整的5.1.3.Final变更日志可以在这里找到。Maven工件位于JBoss Maven仓库的GAV org.hibernate:hibernate-validator:5.1.3.Final下，并且分发包可以在SourceForge上找到。

如果您正在使用5.1版本的Validator，强烈建议升级到5.1.3.Final。为什么不试试5.2 Alpha版本呢？

欢迎通过Hibernate Validator 论坛或使用hibernate-validator 标签在StackOverflow上提问。

祝您使用愉快！

返回顶部