Adding a further constraint to prevent situations where developers forget to add constraints feels a bit clumsy to me, not to mention verbose. I can see how this might be useful to one person, but I wouldn't want the mess of a team applying this inconsistently. I'd prefer convention over configuration in this instance, personally.
On Wednesday, 2 January 2013, Emmanuel Bernard <emmanuel@hibernate.org> wrote:
> Hello,
>
> Matthew argues for a new basic constraint named `@Nullable`. The goal is
> to make it clear when an element is nullable. Today you can guess it
> from the fact that it does not host a `@NotNull` constraint. But it's
> ambiguous as someone might have simply forgotten the constraint.
>
> https://hibernate.onjira.com/browse/BVAL-341
>
> I am not in favor of this for a few reasons. I think what Matthew is
> after is `@Nullable` with the semantic of JSR 305: the element is always
> nullable no matter what - and possibly can be computed by a tool at
> compile time. But since Bean Validation is only validated at specific
> moments in the life cycle of an object or method and that different
> groups can be validated, I don't feel that `@Nullable` would bring all
> the promises one would expect.
>
> Thoughts?
>
> Emmanuel
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>