[bv-dev] Method validation - cont'd

[Hardy Ferentschik]

On May 15, 2012, at 4:19 PM, Matt Benson wrote:

> On Tue, May 15, 2012 at 3:28 AM, Hardy Ferentschik <hardy at hibernate.org> wrote:
>> 
>> On May 14, 2012, at 5:18 PM, Matt Benson wrote:
>>>>> * Should method validation methods be defined on j.v.Validator or a
>>>>> dedicated new interface?
>>>> 
>>>> Should be on javax.validation.Validator
>>> 
>>> Destroying backward compatibilty?  Not such a big deal for full-blown
>>> implementations, perhaps, but what about interoperability libraries
>>> that may, for whatever reason, implement javax.validation.Validator?
>>> Shouldn't a user be able to upgrade to a Bean Validation 1.1
>>> implementation and still use libraries built against Bean Validation
>>> 1.0?
>> 
>> I think the interoperability library case is really hypothetical. Do you know
>> of a single such case? I think it is natural that as a specification evolves no
>> methods get added to interfaces. It is a different story to change existing
>> methods since this will break existing clients, but adding new functionality
>> is ok imo.
>> 
> 
> WRT the "naturalness" of an interface's evolution, seemingly this is
> thought of at least by some as a problem, hence:
> - http://cr.openjdk.java.net/~briangoetz/lambda/Defender%20Methods%20v3.pdf

Don't get me wrong. I see your point and if Java would offer such a feature it would be
great, but it doesn't.

> Custom Validator implementations that *would not* break because they
> inherit from org.apache.bval.jsr303.ClassValidator:
> - http://svn.apache.org/repos/asf/bval/sandbox/bval-jsr303-dynamic/provider/src/main/java/org/apache/bval/jsr303/dynamic/DynamicClassValidator.java
> - http://svn.apache.org/repos/asf/bval/sandbox/bval-jsr303-dynamic/provider/src/main/java/org/apache/bval/jsr303/dynamic/NestedValidator.java
> 
> Custom Validator implementations that *would* break due to their being
> directly implemented:
> - http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/validation/beanvalidation/SpringValidatorAdapter.html
> - http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/validation/beanvalidation/CustomValidatorBean.html

Ok, so there are other classes implementing j.v.Validator. Leaves us only with Validator#unwrap to add functionality. As Emmanuel already pointed out,
this forces us to use some untyped unwrap() style method to add features to Bean Validation. Not nice. #unwrap should imo be used for provider specific 
functionality and not for Bean Validation specified features.

--Hardy