May I present, fresh from the roaster, steaming hot and full of flavor - Hibernate Validator 5.1.0.Final. Validator 5.0 to 5.1 was a slow roast, outspread over several releases, but as you know, slow roasting enhances the flavor ;-)
The individual release blog entries highlighted the various changes for each release. Here is just a short summary with pointers to refresh your memory.
The main goal of Hibernate Validator 5.1 was to improve performance and memory footprint after releasing the initial reference implementation for Bean Validation 1.1. We achieved both and squashed several bugs along the way. If you want to know more have a look at HV-589, HV-637, HV-838 and HV-842. In particular the CDI integration (hibernate-validator-cdi) got an overhaul. As per specification, it should be possible to use multiple Bean Validation providers within CDI, selecting between them using qualifiers. In particular something like this should be possible:
... @HibernateValidator @Inject Validator validator; @Inject Validator defaultValidator; ...where the default Validator instance is not Hibernate Validator, but an explicitly via validation.xml configured provider:
<validation-config xmlns="http://jboss.org/xml/ns/javax/validation/configuration" xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <default-provider>com.acme.ValidationProvider</default-provider> </validation-config>Due to a bug this was not working, but now it is :-) See HV-858 and HV-865 for more information.
We also added a couple of new features. The most important one is the introduction of the ValidatedValueUnwrapper SPI. Refer to the Beta1 blog entry for more details. There are also a few new constraints. You can now make use of @Mod10Check, @Mod11Check (which are effectively replacing the now deprecated @ModCheck constraint) and @EAN (see CR1 blog entry). A feature related to the ParameterNameProvider introduced by Bean Validation 1.1 is the ability to use ParaNamer as parameter name provider (see HV-802).
Feedback and questions are welcome via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag. If you want to know where we are heading next, check out the Hibernate Validator Roadmap.Don't wait, upgrade!