Re: [bv-dev] Method validation - cont'd

On Tue, May 15, 2012 at 3:28 AM, Hardy Ferentschik <hardy(a)hibernate.org&gt; 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

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... - http://svn.apache.org/repos/asf/bval/sandbox/bval-jsr303-dynamic/provider... Custom Validator implementations that *would* break due to their being directly implemented: - http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springfr... - http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springfr...