It has been a while since the first alpha release of Validator 5.1, but as the saying goes: Haste makes waste :-) There is a lot going on in the Hibernate universe and over the last few months we have been especially busy with projects like Search and OGM. Not to speak of the new Hibernate website. Sigh, if we just had more contributors lending a hand (hint, hint).

Nevertheless, we found time to also work on Validator and the result is Hibernate Validator 5.1.0.Beta1 with some nice new features and bug fixes. The most notable feature is the introduction of @UnwrapValidatedValue and the corresponding ValidatedValueUnwrapper SPI (see HV-819). The idea is that in some cases the value to validate is contained in a wrapper type and one would have to add custom ConstraintValidator implementations for each constrained type and constraint. Think Java 8 Optional or JavaFX Property types. For example in JavaFX you could have:

@NotBlank
@UnwrapValidatedValue
private Property<String> name = new SimpleStringProperty( "Foo" );
Here the intention is to apply the @NotBlank constraint to the string value, not the the Property instance. By annotating name with @UnwrapValidatedValue the Validator engine knows that it has to unwrap the value prior to validation. To be able to do this, you need to also register an implementation of ValidatedValueUnwrapper which specifies how this unwrapping has to happen. You can do this via validation.xml as provider specific property (hibernate.validator.validated_value_handlers) or programmatically via:
Validator validator = Validation.byProvider( HibernateValidator.class )
        .configure()
        .addValidatedValueHandler( new PropertyValueUnwrapper() )
        .buildValidatorFactory()
        .getValidator();
PropertyValueUnwrapper is in this case an implementation of ValidatedValueUnwrapper which tells the Validator engine how to unwrap a Property type and of which type the validated value is. The latter is needed for constraint validator resolution. For more information refer to the online documetnation.

What else is worth mentioning? Thanks to Brent Douglas for profiling of Hibernate Validator and detecting of some potential memory leaks - see HV-838 and HV-842. They are fixed now.

Thanks also to Victor Rezende dos Santos and Shin Sang-Jae. Victor found a problem with the Brazilian CPF constraint which lead to its refactoring HV-808, as well as the deprecation of @ModCheck and the introduction of dedicated @Mod10 and @Mod11 constraints as replacements. Shin on the other hand provided a Korean translation of the ValidationMessages properties bundle.

Last but not least, we also have an improved the memory footprint by reducing the amount of memory consumed by metadata (HV-589).

In total 29 resolved issues. Not bad in my opinion and definitely worth upgrading to Validator 5.1.

Maven artefacts are on the JBoss Maven repository under the GAV org.hibernate:hibernate-validator:5.1.0.Beta1 and distribution bundles are available on SourceForge. Send us feedback either via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag.

Enjoy!


Back to top