<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Today, ConstraintValidator accepts Object and the implementation is responsible for handling the casting and raise an exception if the type is not supported.</div><div><br></div><div>The idea is to get type-safe validator and a discovery mechanism to associate a validator to a given runtime type being validated. The resolution is not 100% complete, you might end up with:</div><div>&nbsp;- no valid validator</div><div>&nbsp;- no way to decide between two or more validators</div><div>and get exceptions at runtime.</div><div><br></div><div>I would really like feedback on it as we could arrange some of these rules to not fail (at least in the latter case):</div><div>&nbsp;- do we want this type-safe + auto resolution algorithm strategy or should we stick with the untyped solution</div><div>&nbsp;- do we want to fail in case of ambiguity or rather choose the first compatible provider?</div><div><br></div><div>Personally I find the feature quite elegant and the metadata can be used by tools to warn a user if a constraint does not match the static type it is applied on.</div><div><br></div><div><b>API and declaration<br></b><div><br></div><div>A more typesafe proposal would be:</div><div><br></div><div>public interface ConstraintValidator&lt;A extends Annotation, T> {</div><div>&nbsp;&nbsp; &nbsp;void initialize(A annotation);</div><div>&nbsp;&nbsp; &nbsp;boolean isValid(T object,&nbsp;ConstraintValidationContext context);</div><div>}</div><div><br></div><div>public class StringSizeValidator implements ConstraintValidator&lt;Size, String> {</div><div>&nbsp;&nbsp; ...</div><div>}</div><div><br></div><div><div>public class CollectionSizeValidator implements ConstraintValidator&lt;Size, Collection> {</div><div>&nbsp;&nbsp; ...</div><div>}</div><div><br></div><div><div>public class MapSizeValidator implements ConstraintValidator&lt;Size, Map> {</div><div>&nbsp;&nbsp; ...</div><div>}</div></div><div><br></div><div><div>public class ArraySizeValidator implements ConstraintValidator&lt;Size, Object[]> {</div><div>&nbsp;&nbsp; ...</div><div>}</div><br></div></div><div><br></div><div>@Constraint(validatedBy={</div><div>&nbsp;&nbsp; &nbsp;StringSizeValidator.class, CollectionSizeValidator.class,&nbsp;</div><div>&nbsp;&nbsp; &nbsp;MapSizeValidator.class, ArraySizeValidator.class} )</div><div>public @interface Size { ... }</div><div><br></div><div>We then need to decide at runtime, which validator needs to be executed.</div><div>Here is a proposed algorithm heavily based on the Java Language Specification (boy it's hard to read it).</div><div><br></div><div><b>Resolution algorithm</b></div><div>The type T of a ConstraintValidator must not make direct use of generics itself.</div><div><br></div><div><i>This is because the algorithm compare the actual type at runtime and such notion would be lost. So you can do ConstraintValidator&lt;Size, Collection> but not ConstraintValidator&lt;Size, Collection&lt;String>>.</i></div><div><br></div><div>For a given runtime object t of type T about to be validated for a given constraint:</div><div>if t is null the first validator in the array of available validators is used.</div><div>otherwise</div><div><br></div><div>A validator accepting U is said to be compliant with the type T if T is a subtype of U according to the JLS chapter 4.10.</div><div><br></div><div>If no&nbsp;compliant&nbsp;validator is found for T, a UnexpectedTypeForConstraint exception is raised.</div><div><i>If a validator is taking the responsibility to dispatch types (ie ConstraintValidator&lt;Size,Object>), it must use the same exception in the same circumstances.</i></div><div><br></div><div>If one&nbsp;compliant&nbsp;validator is found, it is used.</div><div><br></div><div>If more than one&nbsp;compliant&nbsp;validator is found, the one with the most specific parameter is used.&nbsp;The informal intuition is that one parameter is more specific than another if any assignment handled by the first parameter could be passed on to the other one without a compile-time type error.</div><div><br></div><div>Of a given type T, a&nbsp;compliant&nbsp;validator accepting U is considered maximally specific if no other T compliant validator accepting V is such as V is a strict subtype of U. String subtype is defined by JSL chapter 4.10.</div><div><br></div><div>If more than one maximally specific validator is found, a AmbiguousValidatorException is raised.</div><div><br></div><div>WDYT?</div></div></body></html>