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

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