[hibernate-issues] [Hibernate-JIRA] Commented: (HV-421) Reconsider behavior of parameter validation for inheritance hierarchies
Gunnar Morling (JIRA)
noreply at atlassian.com
Tue Feb 8 15:31:05 EST 2011
[ http://opensource.atlassian.com/projects/hibernate/browse/HV-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=39879#action_39879 ]
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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the hibernate-issues
mailing list