I am not so keen on on the SPI idea for now for several reasons. First off, it creates ambiguities. What does a @NotNull or @Null constraint validate, the UIInput instance or the wrapped string? Also in this particular case what you really want to do is UIInput<@Size String> which we will support for Java 8. In fact for this case we will need some sort of additional contract which allows us to extract values. The difference is that in this case there is no ambiguity regarding the constrained type.

For now there are several things which could be done:

• Bundle the required ConstraintValidator implementations as part of the framework and provide them to the user. In this case you can do what you suggest, but we don't have to change the Validator code.
• To avoid the mentioned ambiguities and provide the requested features we could introduce an additional annotation:

  @Size(min=3, max=10)
  @UnwrapValidationValue
  UIInput<String> name
  

  In this case we would still need the spi to register type "unwrapper"s, but at least it becomes explicit on a validation target level. We could have a class level version of the annotation as well which indicates that all values should be unwrapped. The one case which is not covered is multiple constraints on a property where some target the wrapper and some the wrapped value. I guess the meaning of @UnwrapValidationValue in this case would be to apply the unwrapping for all constraints.

• A third option would be:

  @Size(min=3, max=10)
  @UnwrapValidationValue(impl=MyUIUnWrapper.class)
  UIInput<String> name
  

  In this case the unwrap annotation specifies explicitly the unwrapper type (the exact contract of this unwrapper needs to be discussed). In this case we would not even need an additional spi. Everything is made explicit and all information to implement the feature is available. Of course this solution has also the drawback that you cannot mix the target of the constraints. It is either the annotated type itself (no @UnwrapValidationValue or the wrapped value (in case @UnwrapValidationValue is used)

I in particular don't want to introduce something now which is sub optimal in conjunction with the Java 8 work we are going to start soon.

Thoughts?