[bv-dev] Support for constraints on container values (e.g. Collection<@Email String>)

[Emmanuel Bernard]

> On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers at me.com> wrote:
> 
> Let’s say we have the following 2 interfaces:
> 
> public interface CachedValue<V> {
>     V getCachedValue();
> }
> 
> public interface RealValue<V> {
>     V getRealValue();
> }
> 
> Based on this interfaces we can easily create a new class that implements both interfaces:
> 
> public class CachableValue<V> implements CachedValue<V>, RealValue<V> {
> 
>     private V cachedValue;
> 
>     @Override
>     public V getCachedValue() {
>         return cachedValue;
>     }
> 
>     @Override
>     public V getRealValue() {
>         V realValue = receiveValueFromServer();
>         cachedValue = realValue;
>         return realValue;
>     }
> 
>     private V receiveValueFromServer() {
>         return ServerConnector.getCurrentValue(); //Some fake code
>     }
> }
> 
> Let’s try to add a constraint annotation to validate the content of such a CachableValue:
> 
> private CachableValue<@NotEmpty String> myValue;
> 
> Based on this definition you have absolutely no idea if the @NotEmpty annotation is defined for the real value, the cached value or both values. From my point of view this is a big problem. Until now its was always easy to see how the validation of a model should work based on the validation information (annotations) in the model. With this new approach you have no idea what will happen.
> 
> The most simple solution would be to add the support only to some special container / wrapper classes like collections, JavaFX properties, etc. I think this is a bad idea since new default might come to future versions of JavaSE and JavaEE (or maybe Spring) and that won’t be supported. Based on this I think that it will be a must to support all wrapper types. 

Interesting.

I did think about extractors of subtypes but not extractors of parallel types.
I have been thinking about it and explored a few paths:
- validating all parallel extractors
- use one
- validate none
- fail

In the end, I think the cleanest solution is to follow what Ceylon and Java do for default methods, they don’t allow ambiguous use and force a redefinition.
http://stackoverflow.com/questions/16764791/how-does-java-8-new-default-interface-model-works-incl-diamond-multiple-inhe#16788295 <http://stackoverflow.com/questions/16764791/how-does-java-8-new-default-interface-model-works-incl-diamond-multiple-inhe#16788295>

In practice for us, if there are extractors for CachedValue and for RealValue, then CachableValue should fail and require the definition of an explicit CachableValue extractor.
What is interesting in this case is that CachableValue extractor can be see as either:
- a ManyContainerValuesExtractor that will return getCachedValue and getRealValue just like a Collection would return get(0) and get(1). This approach does not reflect the path difference though
- or two SingleContainerValueExtractor from the same container type and the same value type (*)

(*) this is something we do not allow for the moment, we have a unique extractor per container + value type. We need to think about how to make that work and still allow people to override extractors.

So back to your original concern of uncertainty, I think forcing a more specific extractor solves the uncertainty that you mentioned. Granted, the user would have to know the extractor(s) behavior but in many ways, people do need to know about that regardless.

Thoughts?

Emmanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161121/bc3cab20/attachment.html