Re: [bv-dev] On the support for Optional (was Re: Support for constraints on container values (e.g. Collection<@Email String>))

Yes, probably we should not support Optional for fields. Also parameters are dubious (the JDK team discourages that afaik). But supporting it for return values (and getter-based properties) seems reasonable. 2016-11-21 14:32 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > > On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers(a)me.com&gt; wrote: > > I don’t think that support for Optional is that important since having a > field of type Optional looks like an anti-pattern to me. Normally Optional > should be used as a method return type and not as a type for a field. > Supporting it in the bean validation might end in strange model classes. > > Example: > > The following model looks good to me: > > public class Model { > > @NotNull > private String name; > > public String getName() { return name; } > > public void setName(String name) { this.name = name; } > > public Optional<String> name() { return Optional.ofNullable(name);} > > } > > On the other hand this looks like an anti-pattern to me: > > public class Model { > > @NotNull > private Optional<String> name; > > public Optional<String> getName() { return name; } > > public void setName(String name) { this.name = > Optional.ofNullable(name); } > > } > > > Yes Optional on a property is deemed an anti pattern by the JDK team but > since Bean Validation supports contraints on method parameters and return > values, this is still a valid use case > > Optional<@Email String> getUserEmail(@NotNull UUID userId); > > Emmanuel > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev