> It is quite uncommon for annotations to use that behavior. Also note that the annotations eg decided not to even offer that option of method overriding.

Exactly. I find it therefore very weird that the BV spec treats the @Valid annotation as being inherited from overridden methods. This conflicts with the guidelines for annotation inheritance as defined in the Common Annotations spec.

Jozef Hartinger What I was describing is the visibility rules of annotations at the Java SE level. Only annotations marked @Inherited are visible on subClass.getClass().getAnnotations(). And that behavior is not available for overridden methods.

Now about Common Annotations, these are guidelines not absolute rules to follow blindly. You can note that some member of the common annotations group did participate in the BV work. The guideline you quote was carefully considered back during the genesis of Bean Validation, but it would unfortunately not make much sense in the context of constraints. You can think of Bean Validation as extending the type behaviors.
In Java you can further restrict the return type in an overridden method. You cannot relax it. It's the same logic here: you can strengthen the return type constraints. Ignoring the annotations would not have worked.