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

[Emmanuel Bernard]

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