[
http://opensource.atlassian.com/projects/hibernate/browse/HV-421?page=com...
]
Gunnar Morling commented on HV-421:
-----------------------------------
I think we even should raise a ConstraintDefinitionException if preconditions for the same
method are defined at multiple places in the hierarchy. That way a user clearly sees what
the problem is instead of wondering why parts of the preconditions are silently ignored.
So this situation would cause an exception:
{code:java}
public class A {
public void foo(@NotNull String s) { ... }
}
public class B extends A {
public void foo(@Size(min=5) String s) { ... }
}
{code}
This also includes the case where the highest version of a method has no constraints at
all, as this already represents a precondition (a very weak one, though) which must not be
strengthened in sub-types:
{code:java}
public class A {
public void foo(String s) { ... }
}
public class B extends A {
public void foo(@NotNull String s) { ... }
}
{code}
Finally no preconditions at all may be used when multiple interface
inheritance/implementation comes into play:
{code:java}
public interface A {
public void foo(String s);
}
public interface B {
public void foo(@NotNull String s);
}
public class C implements A, B {
public void foo(String s) { ... }
}
{code}
If this was allowed, a caller of foo() on a variable with static type A and runtime type C
would have to fulfill the preconditions from B, meaning a strenghtening of the
precondition from A.
I think these restrictions actually seem worse than they are in reality. Implementing
multiple interfaces with the same method should happen very rarely and defining the
precondition at the up-most version of a method should not be a big problem either. WDYT?
Reconsider behavior of parameter validation for inheritance
hierarchies
-----------------------------------------------------------------------
Key: HV-421
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HV-421
Project: Hibernate Validator
Issue Type: Bug
Components: engine
Reporter: Gunnar Morling
Assignee: Gunnar Morling
Fix For: 4.2.0.Beta2
Let A extend B and A#foo() override B#foo(). When validating an invocation of A#foo() the
current implementation will evaluate all parameter constraints defined at A#foo() *and*
B#foo(). That way foo()'s preconditions defined in B are strengthened by A.
According to the ["Programming by
contract"|http://en.wikipedia.org/wiki/Programming_by_contract] article on WP this is
not allowed, subtypes may only weaken preconditions defined by supertypes. The common
implementation pattern for this is to combine the preconditions within a hierarchy by a
logical OR, meaning the weakest precondition in the hierarchy applies.
Note that postconditions (return value constraints) may be strengthened (but not
weakened) by subtypes. Therefore the current implementation (AND combination) should be
correct here.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira