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

[Gunnar Morling]

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 at 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 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
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161121/79a36e76/attachment-0001.html