In Relation To

Back to home

Hibernate Validator 6.0.3.Final released

Posted by    |      

And here comes another maintenance release of Hibernate Validator 6.0.

A lot of thanks to our users and contributors for reporting issues and submitting pull requests, it was definitely a great team effort.

This is a recommended upgrade for everyone using Hibernate Validator 6.0.x and it is a drop-in replacement of 6.0.2.Final.

What’s new

Towards a ScriptEvaluatorFactory SPI

Marko Bekhta worked tirelessly on making the @ScriptAssert and @ParameterScriptAssert constraints more flexible.

We had several goals in mind:

  • Allow to use these features in OSGi environments (we had class loader issues before)

  • Make it possible to use scripting engines not based on JSR 223 (e.g. Spring EL)

  • Instantiate a separate ScriptEvaluatorFactory per ValidatorFactory, whereas it was a static singleton before

Using this new SPI, you can define a specific ScriptEvaluatorFactory either in the XML configuration:

<validation-config
        xmlns="http://xmlns.jcp.org/xml/ns/validation/configuration"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/validation/configuration
            http://xmlns.jcp.org/xml/ns/validation/configuration/validation-configuration-2.0.xsd"
        version="2.0">

    <property name="hibernate.validator.script_evaluator_factory">
        org.hibernate.validator.referenceguide.chapter09.CustomScriptEvaluatorFactory
    </property>

</validation-config>

or via the programmatic API:

Validator validator = Validation.byProvider( HibernateValidator.class )
        .configure()
        .scriptEvaluatorFactory(
                new CustomScriptEvaluatorFactory()
        )
        .buildValidatorFactory()
        .getValidator();

You can find other examples in our documentation, most notably examples allowing to use @ScriptAssert and @ParameterScriptAssert with SpEL (Spring Expression Language) or in OSGi environments.

This new SPI is marked as incubating for now. Feedback welcome!

New @CodePointLength constraint

This new constraint was contributed by Kazuki Shimizu. It allows to add limits to the code point length of a char sequence:

@CodePointLength(min = 1, max = 10, normalizationStrategy = NormalizationStrategy.NFD)
private String text = "が";

Performance and memory allocation improvements

We made another round of performance and memory allocation improvements. Hibernate Validator should be faster than ever!

One thing worth mentioning is that, if you use a custom TraversableResolver, it is now possible to disable the TraversableResolver result cache. The caching adds some overhead and, if your TraversableResolver is fast, you don’t need it. More information can be found in our documentation

OSGi support improvements

Apart from the ScriptEvaluatorFactory SPI, we also made other OSGi improvements.

The OSGi manifest for our CDI module was incorrect and, with the help of Arjan Timjs, we were able to fix it and add an integration test.

Documentation improvements

We made a few improvements to the documentation regarding:

  • the container element constraint feature,

  • the JDK 9 support.

Full changelog

The complete list of fixed issues can be found on our JIRA.

Getting 6.0.3.Final

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.3.Final. Note that the group id has changed from org.hibernate (Hibernate Validator 5 and earlier) to org.hibernate.validator (from Hibernate Validator 6 onwards).

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

If you want to benefit from the new features of this version on WildFly, we also provide WildFly patches for WildFly 10.1 and WildFly 11.0 CR1 (wait for the synchronization to Maven Central). You can read about how to apply such patches here.

Maintenance releases for the 5.3 and 5.4 branches

We also released 5.3.6.Final and 5.4.2.Final with updated JDK 9 support and a fix for CVE-2017-7536 - which only affects users relying on the security manager.

What’s next?

We will continue to release maintenance releases to fix quickly the issues reported by our users.

We updated our roadmap with the ideas we have for the future. If you want to join us, don’t hesitate to pick a task and come discuss it with us.

Feedback, issues, ideas?

To get in touch, use the usual channels:

Back to top