Re: [bv-dev] BVAL-341 - @Nullable
Hi,
I am -1 for adding @Nullable only for the reason described in
https://hibernate.onjira.com/browse/BVAL-341. It is redundant.
In OVal we are using an @Nullable annotation to weaken constraints in
the context of programming by contract.
In the following example on class level is defined that all parameters
of all methods require non-null values, this is then weakened for some
of the parameters using @Nullable. This can be seen as a convenient
approach used e.g. for classes where the majority of parameters must not
be null and only a few should be nullable.
@net.sf.oval.guard.Guarded(assertParametersNotNull = true)
public static class TestEntity
{
protected TestEntity1(final String param1, @Nullable final
String param2)
{ }
public void setParam1(final String param1)
{ }
public void setParam2(@Nullable final String param2)
{ }
}
Regards,
Seb
On 02.01.2013 13:15, Emmanuel Bernard 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