9:46 a.m.
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
4:12 p.m.
Hi Paul,
thanks for your feedback, that's much appreciated.
The reason for the restriction basically is that a client of an API
doesn't necessarily know its implementation. Let's for instance assume
a client receives an implementation of the OrderService interface via
dependency injection:
public class Shop {
@Inject
private OrderService orderService;
...
}
Here, the programmer of the Shop class doesn't know which
implementation will be injected, maybe it's SimpleOrderService, maybe
it's an implementation type not even known to the Shop programmer at
all. If it would be legal to add parameter constraints to the
OrderService implementation, there is no way to find out for the
caller what parameter values for placeOrder() are valid.
Another example is a list, e.g. List<Foo>. When iterating over the
list, each element could be of another type implementing Foo. If
different parameter constraints could be declared by each of these
implementations, how would the caller know which constraints he has to
obey when invoking a method on the list elements?
AFAICS there is not really a difference to this whether one considers
interfaces and implementations or (base) classes and classes derived
from those. In both cases a strengthening of parameter constraints
would be an issue for the caller when polymorphism comes into play.
Design by contract also mentions this limitation, see e.g. the WP
article [1]. Note that some other implementations explicitly allow a
weakening of pre-conditions (by OR-ing the pre-conditions defined in a
hierarchy, effectively applying the weakest one), while the BV
proposal prohibits a re-definition of parameter constraints. So far I
didn't see a good use case for this and felt that allowing a weakening
makes things only more complex, but we can discuss this if we find
good use cases for this.
Does that help answering your question?
--Gunnar
[1] http://en.wikipedia.org/wiki/Design_by_contract
2012/7/17 Paul Benedict <pbenedict(a)apache.org>:
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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
11:51 a.m.
Gunnar, thank you for writing back!
On Tue, Jul 17, 2012 at 4:12 PM, Gunnar Morling wrote:
Hi Paul,
thanks for your feedback, that's much appreciated.
The reason for the restriction basically is that a client of an API
doesn't necessarily know its implementation. Let's for instance assume
a client receives an implementation of the OrderService interface via
dependency injection:
public class Shop {
@Inject
private OrderService orderService;
...
}
Here, the programmer of the Shop class doesn't know which
implementation will be injected, maybe it's SimpleOrderService, maybe
it's an implementation type not even known to the Shop programmer at
all. If it would be legal to add parameter constraints to the
OrderService implementation, there is no way to find out for the
caller what parameter values for placeOrder() are valid.
I see your viewpoint. However, I am not sure BeanValidation needs to
be this smart.
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.
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 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 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);
}
Thanks!
Paul
4496
days inactive
4497
days old
beanvalidation-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Gunnar Morling -
Paul Benedict