[bv-dev] Method validation - cont'd

[Emmanuel Bernard]

On 15 mai 2012, at 16:19, 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
> 
> With Java SE 8 as a dependency I'd give you no argument.  But at least
> one member of the EG belongs to another EG that AFAIK strives
> zealously for backward compatibility.  I'm thinking of Ed Burns and
> JSF.

Even when Java 8 will be there, I don't see defender methods as really solving the problem.
Yes it will give a sense of false safety by not exploding. But what can a spec do to implement
say method validation in a defender method? Besides throwing a NotImplementedException,
not much.

I'm tempted to say that a clean cut is better in some situations. Especially int he adapter business
where the adapter would simply not delegate to the rightful implementation for new methods.

> 
> 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

Right, the approach I like is tougher on people whose business is adapting classes ;)