Hi, I've received some very interesting feedback on the value extraction proposal from our team working on the Ceylon language. Ceylon does not only have its own collection framework, but also custom numeric wrappers, e.g. ceylon.language.Integer. Of course it'd be desirable to be able to apply existing constraints such as @Min to these. Instead of creating custom implementations such as ConstraintValidator<Min, ceylon.language.Integer> we thought value extractors could be used to enable all the existing constraints and validators: @UnwrapByDefault public class IntegerValueExtractor implements ValueExtractor<@ExtractedValue ceylon.language.Integer> { public void extractValues( ceylon.language.Integer originalValue, ValueReceiver receiver) { receiver.value( null, originalValue.getValue() ); } } The problem only is that BV cannot derive the wrapped type (java.lang.Integer) from the annotated extracted value type (ceylon.language.Integer) in this case, as it isn't generic. My question is: should we support this use case? If so, how? One option I can see is allowing to specify the wrapped type explicitly if the wrapper is non-generic: public class IntegerValueExtractor implements ValueExtractor&lt;(a)ExtractedValue(type=int.class) ceylon.language.Integer> { ... } type() would have a default value of void.class, so it doesn't have to be specified if the wrapped type can be derived. We also could decide to not support, requiring integrators such as Ceylon to declare their own constraint validators for BV built-in constraints, but obviously that'd fall short when it comes to 3rd-party custom constraints for basic Java datatypes. Thoughts? --Gunnar