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

Tue Sep 4 15:21:07 EDT 2012

Hi all,

Thanks to everybody chiming into the discussion and participating in
the vote on Doodle [1].

Based on the voting, I think it's safe to say that a majority is
favoring the more strict approach, that is, don't support any
parameter constraint refinement in the spec. What finally let's me
believe that this really is the best approach, was the argument about
adding constraints to legacy interfaces using XML. Providers should be
free to provide alternative approaches (such as OR-ing the constraints
in the hierarchy) based on specific configuration options, annotations
etc.

I've created a pull request for the spec along these lines [2].

Thanks again,

--Gunnar

[1] http://www.doodle.com/qp78u6mqzetuas7p
[2] https://github.com/beanvalidation/beanvalidation-spec/pull/13/files

2012/8/30 Gunnar Morling <gunnar at hibernate.org>:
> Right, XML mappings can indeed be helpful here.
>
> I've written a post on beanvalidation.org [1] asking for feedback from a
> broader audience. Maybe we gain some more insight through this.
>
> --Gunnar
>
> [1] http://beanvalidation.org/news/2012/08/29/methodvalidation-inheritance/
>
> Am 29.08.2012 16:42 schrieb "Hardy Ferentschik" <hardy at hibernate.org>:
>
>> Hi,
>>
>> I voted for the true PbC approach. As I mentioned before I was undecided
>> and can see the
>> Paul's and Matt's point.
>>
>> There are two reasons I voted for PbC now. First I think this the most
>> typical use case where
>> BV method validation will be used and, as Gunnar pointed out, the majority
>> of existing PbC solutions
>> took the no strengthening of preconditions road. The alternative is to
>> allow weakening of preconditions
>> (via ORing the constrains), but this is something we have not even
>> discussed further and would not
>> solve Paul's use case.
>>
>> Which leads me to the second reason I voted for PbC. Emmanuel reminded me
>> of a very important
>> BV feature, the XML configuration. Using it you can specify the
>> constraints easily on the OrderService
>> directly (to use our example again). So for me this covers even this use
>> case without even using a
>> option/flag.
>>
>> --Hardy
>>
>>
>> On 27 Jan 2012, at 4:12 PM, Emmanuel Bernard wrote:
>>
>> > 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
>> >
>> >
>> > _______________________________________________
>> > 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