There is method overriding, but no constructor overriding. Therefore, it seems perfectly fine for me. Regards, Michael On Sat, Jun 30, 2012 at 4:41 AM, Hardy Ferentschik <hardy(a)hibernate.org&gt; wrote: > Hi everyone, > > I hope you had some time to experiment with the functionality in Hibernate Validator 5.0.0.Alpha1. > One question Gunnar and I discussed when implementing the latest spec was constructor validation and constraints on super types. > > Probably best to use an example: > > > public class Foo { > Foo(@Length(max = 10) String s) { > } > > Foo(@Min(5) Integer i) { > } > > public void foobar(@NotNull String s) { > // ... > } > } > > public class Bar extends Foo { > public Bar(String s) { > super( s ); > } > > public void foobar(String s) { > // ... > } > } > > In this case we have Bar extending Foo. What happens if Bar#foobar is called? In this case the @NotNull constraint from > Foo#foobar get applied. So far so good. The question is what happens with constructor validation? > > In the example Bar has one constructor which defines no constraint. The matching super type constructor Foo(String) defines > an @Length constraint. Should this constraint be applied? In the example Bar(String) calls the corresponding string constructor > in the super type, but it might as well call the integer constructor. There is no telling from a Bean Validation point of view. > > For this reason Hibernate Validator does not apply any super types constraints when validating constructors. We think that is > the right behavior, but wanted to run this by everyone. Either way it is probably worth to clarify the spec around this. > > Thoughts? > > --Hardy > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev