Hibernate Validator Migration Guide



This section describes changes made in different releases of version 4.2.0. It helps you to migrate from version 4.1.0.Final to 4.2.0.Final or between releases of version 4.2.0.




This release doesn't introduced modifications which can break your existing code if you have already migrated to version 4.2.0.CR1. If you migrate from version 4.1.0.Final the following sections gives you the changes introduced in the different releases leading to this Final version.


For more details you can see the release note here (coming soon... :-).



  • As you already knows Hibernate Validator allows the configuration of constraints programmatically. The main feature of this release is the programmatic API allowing constraint configuration on method (HV-431). To implement this in an unambiguous way we had to make yet some more changes to the programmatic API. Programmatic API looks like this now:


ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class )
    .property( "manufacturer", FIELD )
        .constraint( new NotNullDef() )
    .property( "licensePlate", FIELD )
        .constraint( new NotNullDef() )
        .constraint( new SizeDef()
            .min( 2 )
            .max( 14 ) )
    .property( "seatCount", FIELD )
        .constraint( new MinDef()
            .value ( 2 ) )
.type( RentalCar.class )
    .property( "rentalStation", METHOD )
        .constraint( new NotNullDef() );



  • Another minor modification which can impact your existing code (if you migrate from Beta2) is HV-488. If you use the method meta data API you will see that the method of MethodDescriptor named getParameterConstraints() was renamed to getParameterDescriptors() to avoid confusion.


For more details you can see the release note here.



The version Beta1 has introduced the possibility to specify constraints on methods. If you use this functionality the following changes will impact your code.


  • A big change introduced in this release is HV-421 which defines the behavior of parameter constraint validation. Generally a logical AND is used to combine all constraints defined within a class hierarchy on a given field or method. Doing the same for method parameter constraints, however, causes ambiguities with the definition of Programming by contract where subtypes may only weaken preconditions defined by supertypes. For this release we chose a conservative alternative which prohibit multiple parameter constraints on the same parameter within a class hierarchy. This mean that the following code isn't correct:


public interface Foo {
     String sayHello(@NotNull String firstName);

public class FooImpl implements Foo {
     String sayHello(@NotNull @Size(max=10) String firstName) {
          return "Hello " + firstName;



  • Another minor modification is that the method MethodValidator#validateParameters() (allowing to validate all parameters of a method) was renamed to MethodValidator#validateAllParameters() (HV-415).


For more details you can see the release note here.



  • BVTCK-12 resp. HV-395 required a change in the javax.validation.Path implementation. Unless you iterate over the Path instance returned by Constraint.getPropertyPath() you are not affected by this change.
  • Programmatic configured generic constraints are now configured like this:


ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Foo.class ) 
.property( "bar", FIELD ) 
   .genericConstraint( MyConstraint.class )
   .param( "value", 1 );



  • When creating own subclasses of ConstraintDef is it not necessary anymore to repeat the definitions ofmessage, payload and groups. ConstraintDef uses now self-referential generic types.


For more details you can see the release note here.