I don't really know what the "'dynamic' land of JSR 303" is, so I can't really answer in any other way than this: the purpose of @Nullable would simply be to remove ambiguity.

Before JSR-303, any time you saw a reference type, you had to ask yourself "Can that be null?" and then dig to find out, either in javadoc, other docs, or code.

After the first release of JSR-303, at least you knew when something was *not* supposed to be null, thanks to the @NotNull annotation (and its opposite, @Null, which I still find a bit odd). However, the lack of a @Nullable annotation leaves an ambiguity that the developer must still resolve as to whether or not a reference is nullable. The developer is left to wonder whether or not the author really meant that the reference should be nullable or whether they just forgot to include the @NotNull annotation or didn't know about JSR-303. With the introduction of a @Nullable annotation, it would be explicit that the annotated reference is allowed to be null.

I could see a nice tooling addition, similar to eclipse's save action "add @Deprecated to elements marked in javadoc as @deprecated", that would add @Nullable to any reference that is not marked @NotNull or @Null.

Now, if that means that we'll have @Nullable everywhere and it's just noise, then fine, close this request as "won't fix", and we'll all go on in our post-JSR-303 world, interpreting an unqualified reference type as necessarily nullable. That seems like a fine default once you know you're in a codebase whose authors know about JSR-303 and have added @NotNull (& @Null) where they should. If, however, being explicit about nullability is valuable, despite the extra characters, then provide the annotation and its validation implementation of always returning true.

I'll leave it to the expert group to discuss & decide. I'm fine with the outcome either way.