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

[Emmanuel Bernard]

What’s the difference between a field and a getter based property?
It is the same for all intended purposes in Bean Validation.

> On 21 Nov 2016, at 15:51, Matt Benson <mbenson at apache.org> wrote:
> 
> On Mon, Nov 21, 2016 at 8:18 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> 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.
> 
> +1
> 
> Matt (with apologies for not having participated earlier in the spec
> 2.0 process)
> 
>> 
>> 2016-11-21 14:32 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>> 
>>> 
>>> On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers at me.com> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> 
>> 
>> 
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev