|
To explain the "second mode" further (lets calls it "Allow Constraint Override" for the purpose of this explanation):
The thought was that requiring that the base class (or interface) method parameter be annotated with the same constraints as the derived class method parameters would indicate to calling code that a ConstraintViolation may occur even if the source would not be indicated. For example (and assuming a NotNullProperty constraint that checks for null in properties of the parameter):
public interface A {
public abstract int m(@NotNull @NotNullProperty({}));
}
public class B implements A {
public abstract int m(@NotNull @NotNullProperty( {"lastName", "firstName"}
));
}
"Allow Constrain Override" mode would require that the constraint types do not change but allows the constraint properties to vary. In "Allow Constrain Override" mode the caller, knowing only the interface, would know that Constraint Violations may occur if validation is invoked on the method call. This preserves, to some useful degree, the Liskov Substitution Principle.
|
