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.<br>
<br><br>On Wednesday, 2 January 2013, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br>> Hello,<br>><br>> Matthew argues for a new basic constraint named `@Nullable`. The goal is<br>
> to make it clear when an element is nullable. Today you can guess it<br>> from the fact that it does not host a `@NotNull` constraint. But it's<br>> ambiguous as someone might have simply forgotten the constraint.<br>
><br>> <a href="https://hibernate.onjira.com/browse/BVAL-341">https://hibernate.onjira.com/browse/BVAL-341</a><br>><br>> I am not in favor of this for a few reasons. I think what Matthew is<br>> after is `@Nullable` with the semantic of JSR 305: the element is always<br>
> nullable no matter what - and possibly can be computed by a tool at<br>> compile time. But since Bean Validation is only validated at specific<br>> moments in the life cycle of an object or method and that different<br>
> groups can be validated, I don't feel that `@Nullable` would bring all<br>> the promises one would expect.<br>><br>> Thoughts?<br>><br>> Emmanuel<br>> _______________________________________________<br>
> beanvalidation-dev mailing list<br>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
>