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

[Paul Benedict]

I think there is a general problem with the application of this rule:
"a method's preconditions (as represented by parameter constraints)
may not be strengthened in sub types"

The problem is that this could hurt API developers who publish basic
interfaces but where implementation designers are free to choose
validations specific to their system. Example 4.11 is a great example:

public interface OrderService {
    void placeOrder(String customerCode, Item item, int quantity);
}

public class SimpleOrderService implements OrderService {
    @Override
    public void placeOrder(
        @NotNull @Size(min=3, max=20) String customerCode,
        @NotNull Item item,
        @Min(1) int quantity) { ... }
}

I can see no good reason why this should be disallowed. The spec is
assuming that because no constraints are on the interface, no
implementation may ever use constraints. This is a poor assumption. It
is actually a blockade to any system that currently exists -- being
created prior to BeanValidation -- who could benefit from adding
method-level validation in their implementation.

This can be easily corrected though. Apply these rules only on
concrete classes. If SimpleOrderService2 extends SimpleOrderService,
then spec should disallow the strengthening of constraints. In
summary, don't consider interfaces (unless the interfaces themselves
have annotated constraints?).

Do you see the problem I am addressing?

Thanks,
Paul