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

Emmanuel Bernard emmanuel at hibernate.org
Mon Nov 21 11:27:43 EST 2016


I have the same feeling and arguments.

> On 21 Nov 2016, at 17:25, Christian Kaltepoth <christian at kaltepoth.de> wrote:
> 
> Not sure I like the idea of supporting Optional<T> for return types but not for fields and method parameters. Is there any technical reason for this restriction? I agree that using Optional<T> for fields is an anti-pattern, but I don't see any reason for not supporting it nevertheless.
> 
> Am I missing something here?
> 
> 2016-11-21 15:18 GMT+01:00 Gunnar Morling <gunnar at hibernate.org <mailto:gunnar at hibernate.org>>:
> 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 at hibernate.org <mailto:emmanuel at hibernate.org>>:
> 
>> On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers at me.com <mailto: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 <http://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 <http://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 <mailto:beanvalidation-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev <https://lists.jboss.org/mailman/listinfo/beanvalidation-dev>
> 
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org <mailto:beanvalidation-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev <https://lists.jboss.org/mailman/listinfo/beanvalidation-dev>
> 
> 
> 
> -- 
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/ <http://blog.kaltepoth.de/>
> Twitter: http://twitter.com/chkal <http://twitter.com/chkal>
> GitHub: https://github.com/chkal <https://github.com/chkal>
> 
> _______________________________________________
> 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/f9ee74e2/attachment.html 


More information about the beanvalidation-dev mailing list