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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev