Agreed that it can be made work for all cases (the RI does it already more or less). Question is whether by supporting e.g. Optional fields we encourage modelling styles that are discouraged by the JDK team. But maybe that's just a question of documentation/wording, i.e. we could support it everywhere but only show usage on return values / getter props in the spec.

> It is the same for all intended purposes in Bean Validation.

There is one subtle difference actually. What should we return from PropertyDescriptor#getElementClass() if the field is Foo, but the getter is Optional<Foo>?

That's a case where our nice unified model falls apart a little bit. One quick thought would be to return Foo and have a new method isOptional(), though that wouldn't answer whether the field or the getter is optional.



2016-11-21 17:21 GMT+01:00 Emmanuel Bernard <emmanuel@hibernate.org>:
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@apache.org> wrote:
>
> On Mon, Nov 21, 2016 at 8:18 AM, Gunnar Morling <gunnar@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@hibernate.org>:
>>>
>>>
>>> On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers@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@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev