Red Hat

In Relation To Hardy Ferentschik

In Relation To Hardy Ferentschik

Hibernate Validator 5.2.1.Final*

Posted by    |       |    Tagged as Hibernate Validator

I know you have been waiting in anticipation, but now it is available - Hibernate Validator 5.2.1.Final :-). Given that it is a drop-in replacement for all 5.x releases, there is no reason to delay an upgrade. Just go and get it.

For the more cautious, here again the highlights of the 5.2 release with pointers to more information.

The highlights

  • Java 8 Support, most notably the ability to validate Optional and the new date/time types. Types, which do not represent an instant on the time-line, however, are not supported out of the box. This includes, for example, LocalDate and its sub-types. Semantically it does not make sense to talk about future and past, if your data type cannot be unambiguously tied to an instant in time. This is still a bit of a open discussion (see HV-981) though. Contact us if you have an opinion.

    Support for Java 8 also includes the use of type annotation constraints like:

    private List<@AcmeEmail String> emails;

    In this case each element of the emails list (or more generally of any Iterable) will be validated using the @AcmeEmail. Note the use of a custom constraint and not the Hibernate Validator provided @Email. The reason is that all provided constraints are missing java.lang.annotation.ElementType.TYPE_USE in their definition for now. Adding it would break backwards compatibility to Java 6.

    Java 8 is not a requirement for Hibernate Validator 5.2. It is still backward compatible with Java 6. Java 8 specific features are only enabled in case a Java 8 runtime is detected.

  • Ability to provide custom constraints discoverable via the Java ServiceLoader mechanism. Under the hood this uses the new ConstraintMappingContributor SPI. read more…​

  • Ability to use Hibernate Validator without dependency to the Expression Language libraries by using the new ParameterMessageInterpolator. read more…​

  • Ability to provide an external ClassLoader. Potentially handy for modularized environments. read more…​

  • Apache Karaf feature file. read more…​

  • Extension of the Path API for nodes of type ElementKind.PROPERTY, which allows to obtain the value of the represented property. read more…​

  • TimeProvider contract. read more…​

  • Tons of bug fixes

Where to get it

Maven artifacts can be found in the JBoss Maven repository, as well as in Maven Central. The GAV is org.hibernate:hibernate-validator:5.2.1.Final. Distribution bundles will be uploaded to SourceForge once it has recovered from its storage fault.

What’s next

Further development will be driven by the upcoming Bean Validation update - Bean Validation 1.2. Most likely this will align with a Hibernate Validator 6 requiring Java 8. This will be necessary to make use of all the new features Java 8 offers, amongst others the use of @Repeatable. This is in alignment with other technologies which are part of the Java EE 8 standard.

Watch for changes to the Hibernate Validator roadmap, as well as announcements on this and the Bean Validation blog.

Let us know what you think

Feedback and questions are welcome via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag. If that is not enough, check out the other ways you can get in contact with us.

Thank you

Last but not least, a big thank you to all of you who were lending a helping hand along the way, be it via a bug report or more hands on via a pull request. Special thanks to Khalid who kicked of the work on the 5.2 release series with his Google Summer of Code work. Thank you also for the smaller contributions provided by Denis Tiago, Nicolas Francois, Xavier Sosnovsky, dernasherbrezon, stawny and tonnyyi. Finally a thank you to all other Hibernate team members who were involved.


* In case you are wondering what happened with 5.2.0.Final, it became obsolete while waiting for SourceForge to recover. In the meantime an IBM JVM specific issue (HV-1007) was reported and fixed.

Moving along towards a 5.2 Final, we are happy to announce the release of Hibernate Validator 5.2.0.CR1. The main goal of this release was to fix bugs and polish some of the new features. For example, we reviewed the Optional validation support and made sure its behavior is (what we think) consistent in all cases. You can find the full change log on JIRA.

Despite the focus on bug fixes, we still managed to sneak in a couple of new features. Hibernate Validator offers now a TimeProvider contract, as well as an extension of the Path API which allows to obtain the value of the represented property. Refer to the online documentation for more information.

Another more general question, which created quite a bit of discussion, revolved around the validation of Java 8 date/time types (JSR 310) (see HV-874). The question is, whether we can/should provide default ConstraintValidator implementations for @Past and @Future validating LocalDate (or any of the other date/time types which do not represent a instant in time). The Javadocs tells us:

This class does not store or represent a time or time-zone. Instead, it is a description of the date, as used for birthdays. It cannot represent an instant on the time-line without additional information such as an offset or time-zone.

Without a instant in time, however, past and future are undefined. One can only validate such an instant by associating a timezone with it. But which one? The time zone of the current JVM? That could lead to unexpected behavior for example in client-server applications. If you have an opinion on this or an idea on how to solve this, please leave a comment or use any of the other means listed below to get into touch with us. We would love to hear from you. For now, Hibernate Validator will not support LocalDate out of the box. We will see how this pans out.

Where do I get the release?

Maven artifacts can be found in the JBoss Maven repository (GAV org.hibernate:hibernate-validator:5.2.0.CR1) and will within a short time also be synced to Maven Central. Distribution bundles are as usual available on SourceForge.

Feedback and questions are welcome via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag.


Following on the heels of 5.2.0.Final, Hibernate Search 5.3.0.Beta1 is now out. This time the faceting engine got an overhaul.

This work was long overdue, because there were several shortcomings with the existing implementation. For example, there were limitations with *ToMany associations. Also, the implementation was based on a custom Lucene Collector making use of the FieldCache API. FieldCache will be removed in Lucene 5, so updating the faceting API was also a requirement for upgrading to Lucene 5 in the near future.

What has changed? Actually not much when it comes to the API Hibernate Search exposes. You still create your FacetingRequest using QueryBuilder.facet().... You then enable the facet search by passing it to the FacetManager from which you also then retrieve the list of Facet instances after the query was executed. All this is unchanged and documented in the online documentation.

A few things have changed though. Most notably, you will need to tell Hibernate Search now which properties are used for faceting. You do so by adding @Facet (resp. @Facets) to these properties. The reason for this is, that under the hood the implementation is now based on Lucene's dynamic faceting capabilties. For this to work, we need to index the facet values using the appropriate DocValues type (SortedSetDocValuesFacetField, NumericDocValuesField or DoubleDocValuesField). Below we see the use of the @Facet(s) annotation:

    public class Quux {
        private Integer id;
        @Field(analyze = Analyze.NO),
                @Facet(name = "string_facet_value", encoding = FacetEncodingType.STRING)
        private double value;
Notice that in this example the value field is configured with two facet annotations. The reason is, that per default numbers will be stored using numeric DocValues types (NumericDocValuesField and DoubleDocValuesField), whereas all other types use string based SortedSetDocValuesFacetField. Numeric values can then only be used with a range facet whereas discrete facets require string values. In the case where you want to use discrete faceting on a numeric field (for example if the field only contains a fixed number of possible values) FacetEncodingType.STRING needs to be used.

This is inline with the fact that Hibernate Search 5.x indexes numbers now per default numerically (see this blog).

A final caveat - there was a change in the default behaviour of includeZeroCounts as part of a facet request. The default was to include zero counts, but has changed now to not include it. Instead it must be explicitly specified (calculating zero counts for discrete facets comes with a performance penalty!):

    FacetingRequest request = queryBuilder( Car.class ).facet()
            .name( "quuxFacetRequest" )
            .onField( "string_facet_value" )
            .includeZeroCounts( true )

Release info for Hibernate Search 5.3.0.Beta1

  • Full change log is available on JIRA
  • Artefact jars are available on Maven Central under the GAV org.hibernate:hibernate-search-orm:5.3.0.Beta1
  • Zip and tar bundles on SourceForge

Happy faceting!

Hibernate Validator 5.2.0.Beta1 - a joint effort!

Posted by    |       |    Tagged as Hibernate Validator

We are happy to announce the release of Hibernate Validator 5.2.0.Beta1. This time a whole bunch of Hibernate team members (Davide, Emmanuel, Gunnar, Sanne and myself) joined forces to make this release happen. Thanks everyone!

In total we were able to resolve 30 issues. Here are some highlights.

Ability to provide external ClassLoader

There are several cases in which Hibernate Validator needs to load resources or classes:

  • XML descriptors (META-INF/validation.xml as well as XML constraint mappings)
  • Classes specified by name in XML descriptors
  • ValidationMessages resource bundle

By default Hibernate Validator tries to load these resources via the current thread context classloader. If that’s not successful, Hibernate Validator’s own class loader will used as a fall-back. For cases where this strategy is not appropriate (e.g. modularized environments such as OSGi), you can now provide an external class loader during bootstrapping:

Validator validator = Validation.byProvider( HibernateValidator.class )
    .externalClassLoader( classLoader )

Hibernate Validator features.xml for Apache Karaf

As a side effect of the class loader improvements we were able to write some OSGi integration tests between Apache Karaf and Hibernate Valdiator. The tests themselves are not so important, but we decided to release the required Karaf features.xml file as part of our regular build artifacts. You can view the first version of this file here.

Programmatic constraint mapping via ConstraintMappingContributor

In Hibernate Validator you can, as a provider specific feature, programmatically define constraint mappings. So far this feature was tied to a programmatic bootstrapping of the ValidatorFactory itself. However, often you are not bootstrapping the factory yourself, but work with the default factory as configured via META-INF/validation.xml. In these cases you can now add one or more programmatic constraint mappings by implementing a ConstraintMappingContributor:

public static class MyConstraintMappingContributor implements ConstraintMappingContributor {

        public void createConstraintMappings(ConstraintMappingBuilder builder) {
                        .type( Marathon.class )
                                .property( "name", METHOD )
                                        .constraint( new NotNullDef() )
                                .property( "numberOfHelpers", FIELD )
                                        .constraint( new MinDef().value( 1 ) );

                        .type( Runner.class )
                                .property( "paidEntryFee", FIELD )
                                        .constraint( new AssertTrueDef() );

In order for this ConstraintMappingContributor to get picked up by the bootstrap process, you then need to specify the fully-qualified class name of the contributor implementation in META-INF/validation.xml, using the property key hibernate.validator.constraint_mapping_contributor.

ConstraintDefinitionContributor with resource bundles

We introduced ConstraintDefinitionContributor already in the Alpha1 release, but it so far only allowed you to contribute constraints. Default messages via a resource bundle were not covered. This has changed, and you can just place a and/or its locale-specific specializations at the root your JAR. Hibernate Validator will aggregate the entries from all the bundles with this name found on the classpath.

Where do I get it?

Maven artifacts for this release are in the JBoss Maven repository (GAV org.hibernate:hibernate-validator:5.2.0.Beta1) and on SourceForge.

Feedback and questions are welcome via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag. If that is not enough, check out the other ways you can get in contact with us.


Hibernate Search 5.0.0.CR2

Posted by    |       |    Tagged as Hibernate Search

While working on the finishing touches for Hibernate Search 5 and updating the projects integrating with Hibernate Search, we discovered a couple of issues which we needed to address to proceed. So without further ado, here comes:

Hibernate Search 5.0.0.CR2


Hibernate Search 5.0.0.Beta2 released

Posted by    |       |    Tagged as Hibernate Search

I am happy keep the Hibernate Search 5 release train rolling by announcing Hibernate Search 5.0.0.Beta2. Download it from the JBoss Maven Repository using the GAV org.hibernate:hibernate-search:5.0.0.Beta2 or from SourceForge. The full change log is available via the JIRA release notes.

As Sanne mentioned on the Beta1 release blog, it is all about getting the final release of Search 5 over the finish line. The resolved issues are mostly minor and center around polishing API and documentation. In particular the geospatial support got a bit of an overhaul. One issue, however, stands out of the crowd - HSEARCH-1699. It deals with how synchronous index updates are applied. You as user are probably only interested in the indexing performance you gain (our initial tests show they are considerable and we will follow up with some numbers). Still, in case you want to know more, refer to the JIRA issue which outlines the gory details.

Make your voice heard and give us your feedback, for example via the mailing list or on IRC.


After some time in the making, we are happy to announce the first Hibernate Validator release of the 5.2 series - 5.2.0.Alpha1. This release focuses mainly on Java 8 support, but we will get to this in a bit.

First a big thank you to Khalid Alqinyah who, as part of a Google Summer of Code project, implemented many of these new features.

So what's in it for you?

Java 8 support

Note: Java 8 is not a requirement for Hibernate Validator 5.2. Hibernate Validator is still backward compatible with Java 6. Java 8 specific features are only enabled when a Java 8 runtime is detected.

First off, the Java 8 date/time data types (JSR 310) are supported and can be validated via @Past and @Future. Also Optional and JavaFX types are supported via an improved ValidatedValueUnwrapper. ValidatedValueUnwrapper was already introduced in Validator 5.1, but works now in a more transparent way. Upon validation all registered ValidatedValueUnwrapper instances are checked. If a handler supports the validated type its handleValidatedValue method is called, provided that there exists no matching ConstraintValidator for the wrapper itself. This is best explained with an example:

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

@UnwrapValidatedValue(false) // Use @UnwrapValidatedValue(false) to ensure the wrapper itself is validated
private Optional<String> lastName = Optional.of( "Doe" );
Another Java 8 related feature is the ability to use type annotations on Iterable instances. Something like this:
private List<@AcmeEmail String> emails;
Note that the example is not using Hibernate Validator's @Email. Neither Bean Validation's built-in constraints nor Hibernate Validator specific ones, can be used. The simple reason is that these constraints are missing java.lang.annotation.ElementType.TYPE_USE in their definition and it cannot be added in a backwards compatible way. At the moment we have not yet decided what to do. Should we make Java 8 a requirement for Validator 5.2 or should we somehow provide JVM specific artifacts? What do you think? Right now we want to keep the options open and see which path Bean Validation 1.2 and other Java EE 8 standards are taking. For now this feature is limited to custom constraints where you can add the required ElementType yourself.

Last but not least, in the Java 8 driven feature list, is ReflectionParameterNameProvider. This new ParameterNameProvider makes use of enhancements in the Java 8 reflection API and reports actual parameter names instead of the generic arg0, arg1, etc. A requirement for this provider to work is that the sources are compiled with the -parameters compiler option. Refer to the docs to see how to configure a custom ParameterNameProvider.

What else?

Here are a couple of more highlights from this release:

ConstraintDefinitionContributor and ServiceLoader for constraint definitions

The Bean Bean Validation specification allows to register new constraint definitions via XML mapping files. For example:

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

We offer now two more ways of contributing constraint definitions. The first is programmatically via the ConstraintDefinitionContributor SPI. The above example would look like:

HibernateValidatorConfiguration configuration = Validation
        .byProvider( HibernateValidator.class )

        new ConstraintDefinitionContributor() {
                public void collectConstraintDefinitions(ConstraintDefinitionBuilder builder) {
                        builder.constraint( URL.class )
                                .includeExistingValidators( false )
                                .validatedBy( RegexpURLValidator.class );

By the way, org.hibernate.validator.constraintvalidators.RegexpURLValidator is not a made up class. It is another new feature (HV-920) which allows to configure a regular expression based validator for the @URL constraint.

Back to constraint definition though. The second way to contribute constraint definitions is via the Java ServiceLoader mechanism. Just add META-INF/services/javax.validation.ConstraintValidator to your artifact listing the fully qualified classnames of your constraint validator classes (one per line). This mechanism works fine for adding constraint definitions for new types. You cannot as possible in XML or via the ConstraintDefinitionContributor disable default definitions.


Hibernate Validator requires per default an implementation of the Unified EL to be available. For environments where you cannot or do not want to provide an EL implementation, we offer now a non EL based message interpolator - org.hibernate.validator.messageinterpolation.ParameterMessageInterpolator.

Warning: Constraint messages containing EL expressions will be returned un-interpolated!

These were just the highlights. In total a whopping 40 issues got resolved. Be one of the early adopters and get the Maven artifacts from the JBoss Maven repository (GAV org.hibernate:hibernate-validator:5.2.Alpha1) or the SourceForge distribution bundles.

Simultaneously with the 5.2 alpha release we published a 5.1 maintenance release. We accidentally broke Java 6 backwards compatibility in 5.1.2.Final by using Collections#emptyIterator(). This is corrected in 5.1.3.Final and Java 6 compatibility is restored.

The second bug fixed in 5.1.3.Final is HV-930 where constraints were not validated when the internal weak reference cache of Hibernate Validator got partly invalidated due to memory pressure.

The full 5.1.3.Final change log can be found here. Maven artifacts are on the JBoss Maven repository under the GAV org.hibernate:hibernate-validator:5.1.3.Final and distribution bundles are available on SourceForge.

If you are using a 5.1 version of Validator it is highly recommended to upgrade to 5.1.3.Final. Or why not giving the 5.2 Alpha version a go?

Feedback and questions are welcome via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag.


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:

Validator validator;

Validator defaultValidator;
where the default Validator instance is not Hibernate Validator, but an explicitly via validation.xml configured provider:
<validation-config xmlns=""
                   xsi:schemaLocation=" validation-configuration-1.1.xsd"
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).

Maven artifacts are as usual on the JBoss Maven repository under the GAV org.hibernate:hibernate-validator:5.1.0.Final and distribution bundles are available on SourceForge.

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!

I am happy to announce Hibernate Validator 5.1.0.CR1, hopefully (fingers crossed) the last release prior Final. We used the release for last adjustments and some bug fixes.

On the bug fix side, we addressed issues with the CDI integration (HV-858), EL message interpolation (HV-834) and validated value unwrapping in conjunction with Validator#validateValue and Validator#validateProperty (HV-860).

We also gave @Mod10Check and @Mod11Check a final overhaul and made the parameter naming more consistent and changed the semantics of startIndex, endIndex and checkDigitIndex. They are now all inclusive and always relative to the original validated value, indepent of ignoreNonDigitCharacters. If you are already using these new constraints, I recommend you review the linked Javadocs to understand the updated semantics.

Last but not least, we added yet another checksum related constraint - @EAN. It allows you to validate International Article Numbers (EAN-13 and EAN-8).

The full change log can be found here. Maven artefacts are on the JBoss Maven repository under the GAV org.hibernate:hibernate-validator:5.1.0.CR1 and distribution bundles are available on SourceForge.

Feedback and questions are always welcome via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag.


Hibernate Metamodel Generator has moved

Posted by    |       |    Tagged as Hibernate ORM

This is just a quick note that the Hibernate Metamodel Generator code has moved and is now, as of version 4.3.0.Final, part of Hibernate ORM. You can find it in the tooling/metamodel-generator sub-directory of ORM. Unfortunately this news have been falling under the table during the announcement of ORM 4.3.0.Final. After all the focus was on JPA 2.1 support :-)

There are several reasons for the move. For one, we hope that the generator will get a greater exposure within the ORM code-base and that it will benefit from the more regular ORM release schedule. For another, the generator fitted nicely into the newly created collection of Hibernate ORM tooling artifacts (check for example the maven/gradle plugins for byte code enhancement). Code wise nothing has changed. The annotation processor is still agnostic of the JPA provider and can be used with any provider to generate the metamodel classes for type-safe criteria queries. So what has changed:


back to top