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

On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers(a)me.com&gt; 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.