<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">+1 for the support<div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class="">Marco</div><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 9 May 2017, at 18:57, Michael Nascimento <<a href="mailto:misterm@gmail.com" class="">misterm@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">They are Java SE 8 APIs, so they must be supported. From the point of the view of the user, nothing will change, so let's support them now.<div class=""><br class=""></div><div class="">Regards,</div><div class="">Michael</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 9, 2017 at 10:36 AM, Gunnar Morling <span dir="ltr" class=""><<a href="mailto:gunnar@hibernate.org" target="_blank" class="">gunnar@hibernate.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="">
<br class="">
I'm curious about your take on supporting the types in ${subject}<br class="">
(BVAL-579 [1]).<br class="">
<br class="">
They are non-generic wrappers for int, long and double. Should we<br class="">
support them with the numeric constraints such as @Min et al.? The<br class="">
easiest way to do so would be to just mandate support in the JavaDoc<br class="">
of the numeric constraint types.<br class="">
<br class="">
The only thing I can see speaking against this is that we may migrate<br class="">
to an extractor-based approach in a future revision. Currently<br class="">
extractors cannot be used, as those types don't have any type<br class="">
parameter which could be extracted. But assuming we extend the<br class="">
extractor API in a future revision to deal with non-generic types,<br class="">
too, we could then rather mandate built-in extractors for those types.<br class="">
Which will allow to put *any* constraint applying to int also to<br class="">
OptionalInt.<br class="">
<br class="">
Should we do such change in a future revision, I don't think anything<br class="">
would change for users. Only providers would have to implement support<br class="">
for these types via extractors instead of dedicated constraint<br class="">
validators. I think such change is acceptable.<br class="">
<br class="">
What do others think?<br class="">
<br class="">
Thanks,<br class="">
<br class="">
--Gunnar<br class="">
<br class="">
[1] <a href="https://hibernate.atlassian.net/browse/BVAL-579" rel="noreferrer" target="_blank" class="">https://hibernate.atlassian.<wbr class="">net/browse/BVAL-579</a><br class="">
______________________________<wbr class="">_________________<br class="">
beanvalidation-dev mailing list<br class="">
<a href="mailto:beanvalidation-dev@lists.jboss.org" class="">beanvalidation-dev@lists.<wbr class="">jboss.org</a><br class="">
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank" class="">https://lists.jboss.org/<wbr class="">mailman/listinfo/<wbr class="">beanvalidation-dev</a><br class="">
</blockquote></div><br class=""></div>
_______________________________________________<br class="">beanvalidation-dev mailing list<br class=""><a href="mailto:beanvalidation-dev@lists.jboss.org" class="">beanvalidation-dev@lists.jboss.org</a><br class="">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</div></blockquote></div><br class=""></div></div></body></html>