10:08 a.m.
Gunnar, I address some of your points below...
On Thu, Jul 19, 2012 at 2:02 AM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Am 18.07.2012 18:51 schrieb "Paul Benedict"
<pbenedict(a)apache.org>:
> Let's make up an example.
> 1. OrderService is a popular interface in the public domain for several
> years.
> 2. OrderService was created years before BeanValidation exists.
I don't see a difference depending on when an interface was written. Imagine
it would be allowed to add parameter constraints in implementations of
java.util.List. Such an implementation would potentially break all code
written against the List interface which is not aware of the additional
constraints.
> 3. OrderService constraints are documented in the javadoc. A custom
> Exception type is thrown.
> 4. A new vendor wishes to implement SimpleOrderService using Bean
> Validation. Their plan is to capture ConstraintViolationException and
> marshall it to the custom Exception type.
The idea behind BV method validation is that some integration layer (e.g.
CDI, AOP,based etc.) performs the constraint validation. So any
ConstraintViolationException would not be reachable from within
SimpleOrderService, as the call flow wouldn't get there.
>
> The new vendor will not be able make such a design under the current
> spec. This is where the rub lies: assuming the lack of BeanValidation
> means the validation constraints are specified. Is this sensible?
> Actually, in this case, no constraints assumes all data is
> automatically valid.
I'm not sure whether I can follow.
Sorry if my point was not clear enough. Let me try again. You
emphasized that you don't want a subclass to be more constrained than
its superclass. So if a superclass does not use BeanValidation,
neither can its subclass. What are the implications? One implication,
as I pointed out, is that is automatically declares all method
parameters as valid. Nothing is constrained and thus all method
parameters are licit.
>
> I believe it should be the opposite -- constraints are undefined.
> Because a plethora of popular interfaces exist without BeanValidation,
> the spec should give leniency to the situation.
>
> Would you consider a new annotation that prevents the strengthening or
> loosening of validation? Perhaps you need something like this:
>
> @ValidationConstraintsComplete
> public interface OrderService {
> void placeOrder(String customerCode, Item item, int quantity);
> }
At the moment I don't see that this would help. If OrderService was written
without BV in mind, the annotation can't be added there. If it was written
with BV in mind, why not placing any parameter constraints on the interface?
In my example, OrderService was not written with BV in mind. But, also
in my example, I am not in control of that interface -- it has been in
the public domain for several years. I am not able to claim it as my
own and begin modifying it. It's history written in stone. I imagine
99% of the Java world is using interfaces without BV 1.1 in mind.
For those maintaining custom validation code in implementations, I say
let them chuck it in favor of BV 1.1 functionality.
Thus I believe we have two use cases here.
1) Designer A makes interfaces with validation unspecified.
2) Designer B makes interfaces with validation specified.
I aptly addressed Designer A's concerns. For where Designer B wishes
no validation extensibility to be had, @ValidationConstraintsComplete
can be added.
Paul