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

[Emmanuel Bernard]

Just to get a better understanding of the dynamic here.
Can you all vote on what you think is the best approach for Bean Validation 1.1
http://www.doodle.com/qp78u6mqzetuas7p

On 26 août 2012, at 09:42, Paul Benedict wrote:

> I was reading the Hibernate Validator documentation today. Here was
> something that speaks to Gunnar's intentions:
> 
> "When validating an object that implements an interface or extends
> another class, all constraint annotations on the implemented interface
> and parent class apply in the same manner as the constraints specified
> on the validated object itself."
> 
> I buy into this 99% except when the parent class has no annotated
> constraints. Why not just make an exception for this case? I think
> that is so incredibly more reasonable than adding a custom
> implementation flag. Since constraints are meant to be compounded, a
> child should be able to add new constraints even if the parent never
> did.
> 
> Paul
> 
> On Wed, Aug 22, 2012 at 3:26 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> Gunnar, do you want to take the lead on 1. and 2.?
>> 
>> Sure, I can do that. I'll prepare a blog post.
>> 
>> Personally, I'm still reserved about adding such a feature. Maybe I
>> would change my mind if someone pointed out to an existing PbC
>> solution which provides such sort of feature/switch. What I've seen so
>> far is either prohibiting parameter constraints in sub-types (as we
>> currently do) or OR-ing all parameter constraint contracts in the
>> hierarchy (effectively applying the weakest one).
>> 
>> An implementation-specific configuration switch might be a good
>> compromise. The spec still may define the current behavior as default
>> and mention that implementations may add means of configuring this.
>> 
>> --Gunnar
>> 
>> 
>> 2012/8/22 Emmanuel Bernard <emmanuel at hibernate.org>:
>>> Reopening the debate here.
>>> 
>>> Matt, java.util.Deque.push actually does describe the risk of NPE depending on the implementation.
>>> 
>>> Let's take the OrderService that has been designed pre-BV 1.1 and that expressed constraints per JavaDoc. There are two options today to make it work:
>>> 
>>> - update it to add Bean Validation 1.1 annotations in compliance with the JavaDoc
>>> - use BV's XML capability to add constraints on the interface without having to touch it
>>> 
>>> Note that adding constraints not described on the interface javadoc would be a change of contract.
>>> 
>>> But I do hear Paul's concern as well. With all the interfaces around, do we want to force people to host their constraints on them instead of on the implementation?
>>> How much of this is a usability constraint? On the other hand, today we enforce good practice. If we open up the Pandora box, there is no way to close it.
>>> 
>>> I'd go and do a few things:
>>> 
>>> 1. open up a JIRA with a summary of the problem
>>> 2. blog about it on beanvalidation.org and push people for feedback
>>> 3. get people to try a preview and give us feedback
>>> 
>>> Gunnar, do you want to take the lead on 1. and 2.?
>>> 
>>> If we are still on the fence, I'm tempted to let implementations provide an implementation specific configuration switch.
>>> 
>>> Sebastian, OVal has had such features for a while AFAIK, what is your take on the subject?
>>> 
>>> Emmanuel
>>> 
>>> On 23 juil. 2012, at 20:38, Paul Benedict wrote:
>>> 
>>>> I concur with Matt's point below. Because there hasn't been a
>>>> validation standard for most of Java's lifetime, most method
>>>> constraints are in javadoc contracts only. I think it's important for
>>>> the BV spec to recognize this fact -- not every precondition is
>>>> available for introspection at runtime. Thus, there is a long pedigree
>>>> here of people who could benefit from BV, if only by chucking their
>>>> custom validation code for BV.
>>>> 
>>>> The OrderService is a great example due to the total absence of BV
>>>> annotations. I don't think the spec should assume the lack of BV
>>>> annotations is an intentional use of BV (i.e., no constraints). I can
>>>> only see two ways out of this problem to address this fact. Either
>>>> annotate OrderService to signify its validation is undefined or
>>>> annotate OrderService to signify validation is intended. Thoughts?
>>>> 
>>>> Paul
>>>> 
>>>> On Mon, Jul 23, 2012 at 9:16 AM, Matt Benson <mbenson at apache.org> wrote:
>>>>> Okay, point taken.  Thanks for clarifying the distinction between
>>>>> pre/post-conditions corresponding to method parameters vs. return
>>>>> values here.  Still, consider the JDK itself:  the java.util.Deque
>>>>> interface imposes no requirements on the parameter to its #push()
>>>>> method, yet the java.util.ArrayDeque implementation forbids null
>>>>> elements and is declared as throwing an NPE if the parameter to
>>>>> #push() is null.  I can fully understand your assertion that this
>>>>> violates DbC and even basic OO principles, but is it *necessary* that
>>>>> BV deny users the option to work with such a design?  I'm not yet
>>>>> convinced of the harm it would cause, beyond implementation complexity
>>>>> (which IMO doesn't seem extensive), to permit a user to add decoupled
>>>>> validation constraints per Paul's example, or to customize a given
>>>>> implementation as in mine.  Nothing here would prevent the purist user
>>>>> from operating per your recommendations.
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> 
>>> 
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev