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

[Gunnar Morling]

> 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