Re: [bv-dev] Method Validation: Why Example 4.11 should be allowed

Thanks Emmanuel. I am sure the poll will bring interesting results. In the mean time, I am looking for some background information here. I would like to understand this reasoning a bit better. As I said, I was reading the Hibernate Validator guide and read (not news to me) that annotations on beans can be compounded: "Constraint annotations are aggregated if methods are overridden." Yet one of the arguments made to me (against allowing constraint redefinition on methods) is that the caller doesn't know if redefinition occurred. However, I see that's exactly the case today regarding constraint inheritance on beans -- subclasses can add more constraints by overriding superclass methods. So a client might be using a subclass, unbeknownst to the client, that has more constraints than what superclass/interface he compiled against. My question is really why treat validation different between beans and method parameters? Why allow the former but disallow the latter? The way we treat beans today is what I would expect even for method validation (hence my emails). I honestly see no difference so I find the difference in validating behavior puzzling. My question isn't rhetorical so any answer is appreciated to help better understand the opposing perspective. Thank you. Paul On Mon, Aug 27, 2012 at 9:12 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: