1:57 p.m.
2012/5/15 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 15 mai 2012, at 16:19, Matt Benson wrote:
> 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.
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...
> -
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...
Right, the approach I like is tougher on people whose business is adapting classes ;)
I think we should distinguish between interfaces implemented by BV
providers (and possibly integrators) such as j.v.Validator and
interfaces implemented by BV users (such as j.v.ConstraintValidator).
Regarding backwards compatibility, I think we should focus on the
user's perspective and not so much on the integrator's perspective.
Therefore adding methods to the former is ok IMO (users are not
affected), while adding methods to the latter isn't.
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?
With respect to a user library (e.g. a constraint library) I'd say
yes. But with respect to an integration library, I'd consider such a
setup a mis-configuration. The used version of a library integrating
BV should match with the version of BV.
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev