Are you guys working at all with the JSR 305 (FindBugs-type annotations) expert group? The functional overlap is clear, though obviously the application is rather different.

Once interesting thing about JSR 305 in its current form is how it does everything through meta-annotations - that is, @Nonnull isn't just an annotation, it's a meta-annotation that you put on your own "not null" annotation. So theoretically the javax.validation.NotNull class could carry the @javax.annotation.Nonnull annotation, and now FindBugs would automatically check that no-one tries to assign null to that field or method parameter.

IMHO, the functional overlap is only in declaration of constraints because the JSR 305 the check for "error" is done statically and, if dynamically, it will be "online".

THe JSR 303, the check for error will not be "online". Of course the 2 could work together if thats what the programmer wants, but I think it will be JSR 305 the will plug into the JSR 303.

ps.: sry I could find better word then "online" to express myself.

Emmanuel can speak for the group, but in my opinion there is no functional overlap.

JSR-305 is about static analysis. Nothing created in 305 ever makes it into business semantics. JSR-303 is exactly the opposite. We are about binding declarative constraints on *objects*, i.e. data, whereas 305 is constraining *logic.*

Put another way, 305 is like extending the static semantics of the language with keywords (which we can't do practically due to lexicographical constraints). For example, C# has an "override" keyword, in Java this is @Override. Which checks for properly overridden method signature.

Also, though we provide a basic set of annotations out of the box, 303 is about a framework for domain-specific validation, rather than a library of all-purpose validation annotations (we simply can't do the latter).

Bill Pugh and I wanted to start a discussion on the subject. We haven't done it so far.
I am not convinced declaration can be reused. But we wanted to explore reusability of the validation machinery (ie being able to reuse a 303 validation implementation in 305).
Overlapping is not as obvious as it looks at first sight but this need to be explored (note that 305 depends on Java 7 AFAIK and JSR 303 does not).