It might be nice if Constraint implementations received (in initialize) the base Class of the annotated class. This would allow errors about inappropriately annotated types to be exposed while processing annotations rather than during data validation.

The ability to validate such constraints without the actual type are restricted; for example a @Length designed to work on only String classes would only allow String and Object as String is a final class. Extend @Length to work on arrays and it also has to allow any Class.isArray() == true.

Extend @Length to work on CharSequence and it is no longer worthwhile to attempt any checks - unless a class is final, some subclass could implement that interface, and thus it would be possible for the constraint to work properly at runtime.

Because of generics and subclasses, you do not always know the actual targeted type at initialization time. That defeat the original purpose

I think it would work, and it could be really useful.
Imagine:


If the framework could look at the declared type to which it is attaching the specific Contraint instance, it could immediately tell the third annotations is wrong. @NotEmpty accepts Arrays, String, Collection and Map, any subclass will still be accepted. If there were code trying to put a byte in insurance, it wouldn't compile anyway.

It could have some nice consequences:
* tools could use it to produce coding-time warnings
* you won't get RunTimeExceptions for that one value you forgot testing
* separate concerns in Constraint implementation
* faster execution, as implementations can trust the type and forget type checking

Imagine in the case of @NotEmpty I could create an appropriate delegate at initialization time, and always use that one when validate(..) is called, instead of type-testing at each call.

Also if frameworks were supposed to test the validator-validity at initialization, you could get proper warnings for stupid errors like

Emmanuel,
I had sent you some prototypical code implementing this;
Do you remember? the first was a nearly complete patch to Hibernate Validator, but depended on the XClass from annotations.
Then you was worried about the annotations dependency, so I sent you a very simplified single java class to showcase the same concept without any dependency.
In Hibernate Validator it looks like to have more sense to use the XClass, but validator implementation should only return a list of compatible Class files, so the standard wouldn't need to speak about XClass, that would be an implementation detail.

I know you're busy, I'm just writing this down as a reminder as I still think this feature
would be very nice to have included; also other people may be interested about what we discussed.