Re: [bv-dev] Constructor validation

> Note that return type constraints could be refined theoretically and be compliant with the Liskov substitution principle. We might want to still disallow this to limit confusion. It will all depend on the set of use case we can think of. In HV we are currently allowing to define additional return value constraints on methods overridden in sub types, and so far I haven't heard of any problems with that. AFAICS that's also what most programming by contract solutions do. What's your opinion on parameter constraints? Would you prefer to OR-join them or to prohibit constraints in overridden methods at all?

>>> - When you add a method return value constraint to a parameterized >>> method and you do Validator.validate(object), thoses constraints are not >>> evaluated. But when you add a constraint to a getter-style method (which >>> also looks and actually is a method return value constraint). They are >>> evaluated by Validator.validate(object). What if someone wants to add a >>> method return value constraint to a getter-style method, that is not >>> evaluated when Validator.validate(object) is executed but after the >>> method itself has been invoked? In OVal you have to explicitely add the >>> @IsInvariant annotation to getter methods if their constraints should be >>> evaluated too when Validator.validate(object) is executed. If so, OVal >>> will invoke the getter and test the returned value against the >>> constraints specified. >> >> Personally I'd say getters are methods such as any other methods, too. >> So if a getter method is invoked one some bean generally qualifying >> for method validation (however that is decided by the method >> validation integration layer) the method's constraints should be >> validated in the same way as any other method constraints. If the bean >> is validated using Validator#validate(), the getter method's >> constraints should be handled as property constraints as it's the case >> today IMO. > > @IsInvariant is not much different from a group (though a bit more elegant). I don't think we should add something explicit in the spec to address this problem as we already can solve it with groups. > Note that getters are not like ordinary methods, they are (by convention) Java properties and that's exactly what validator.validate processes (properties). Yes, getters are considered as properties for standard bean validation (Validator#validate()). But in the context of method validation I would handle them as return value constraints as on any other method. If I understand correctly, @IsInvariant as described above would be breaking with the current spec behavior as it is needed to explicitly enable a constraint on a getter for property validation, which is in BV the case by default. Using groups for cases, where a getter's constraints should be handled different for property and method validation seems reasonable to me, too.

An additional idea would be some option to apply a getter's constraints also as method parameter constraints on the corresponding setter. So if method validation for that bean is enabled, illegal values couldn't be set at all. Would that be useful?