On Thu, 20 May 2010 23:49:00 +0200, Gunnar Morling <gunnar.morling(a)googlemail.com&gt; wrote: True, this feature might not have too many users, but we have to see the overhead from a user's perspective and not from ours. The effort to implement the current solution lies somewhere between the fully types version (config.type(ShoppingCart.class).getter("items").size().max(30).notNull()) and the completely "untyped" one. As a bonus the required definition classes could be generated via an annotation processor. Given what we have learned so far with annotation processors it should not be too hard to write one. By introducing a package org.hibernate.validator.cfg and the ConstraintMapping class the conceptual overhead is isolated and the integration into the core validator framework was not too hard. Not much different than adding xml configured constraints. True, we don't have to create any new classes within the framework, but to use the API you have to create constraint instances which makes the API not really fluent in the same way as the other APIs we recently introduced. That said, I am not the big fluent API proponent. There are other team members who stand for that ;-) I see the biggest usecase in testing, but as you mention code generation is an option as well. I see the use cases as well, but this is not the job of an annotation processor, since you want to create meta class for all pojos (independent of annotations). Sounds more like a build (maven) plugin. Personally I am still not sure if we take this whole type-safety thing not too far. --Hardy