On Tue, May 15, 2012 at 3:28 AM, Hardy Ferentschik <hardy(a)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.
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...
Matt
--Hardy
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev