<div dir="auto"><div>Nice. I presume the definition would look like:<div dir="auto"><br></div><div dir="auto">implements ValueExtractor<@ExtractedValue (type=Integer.class) OptionalInt></div><div dir="auto"><br></div><div dir="auto">* Should we be really brave and rename or alias that member to value()?</div><div dir="auto">* Should we permit to specify as int.class and force the implementation to wrap? (I haven't tried it, and also haven't been awake very long, but I can't think why it wouldn't work)</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Matt</div><br><div class="gmail_extra"><br><div class="gmail_quote">On May 17, 2017 5:30 AM, "Gunnar Morling" <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Guillaume has looked into adding the type() member to @ExtractedValue<br>
so OptionalInt et al. can be handled via value extractors. All looks<br>
good and the change to the API has already been merged<br>
(<a href="https://github.com/beanvalidation/beanvalidation-api/pull/107" rel="noreferrer" target="_blank">https://github.com/<wbr>beanvalidation/beanvalidation-<wbr>api/pull/107</a>).<br>
<br>
I'll send a PR with the corresponding spec change in a bit. It should<br>
be part of the update to the Public Review Draft which I've planned to<br>
submit to the JCP today. I originally thought I'd have a few more days<br>
time for that, but it turned out that contradictory information was<br>
given on <a href="http://jcp.org" rel="noreferrer" target="_blank">jcp.org</a> (they are going to fix that) and that an update must<br>
not be sent later than 10 days before the PD phase's end.<br>
<br>
Should any issues come up around this change (or anything else, for<br>
that matter) we can address them as part of the Proposed Final Draft,<br>
which we'll need to submit in a bit more than one month from now<br>
(around June 20th).<br>
<br>
Cheers,<br>
<br>
--Gunnar<br>
<div class="elided-text"><br>
<br>
<br>
<br>
<br>
2017-05-11 18:42 GMT+02:00 Matt Benson <<a href="mailto:mbenson@apache.org">mbenson@apache.org</a>>:<br>
> On Thu, May 11, 2017 at 2:31 AM, Gunnar Morling <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br>
>> 2017-05-10 20:39 GMT+02:00 Matt Benson <<a href="mailto:mbenson@apache.org">mbenson@apache.org</a>>:<br>
>>> On Wed, May 10, 2017 at 11:34 AM, Gunnar Morling <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br>
>>>> Hi Matt,<br>
>>>><br>
>>>> Putting the specific spec wording aside for a moment, how would such<br>
>>>> extractor implementation make it possible to tell the wrapped type?<br>
>>>><br>
>>>> When validating a constraint on an element of type OptionalInt, the<br>
>>>> validation engine needs to know that this "behaves as an int", so it<br>
>>>> can determine the applicable constraint validators. For something like<br>
>>>> List<@Email String> we can obtain that information from the type<br>
>>>> argument (so we know we need to look for validators on String), but<br>
>>>> it's not doable for OptionalInt which doesn't bear any hint that it is<br>
>>>> about int. Hence the idea of extending the @ExtractedValue annotation<br>
>>>> to convey that information in such case.<br>
>>>><br>
>>><br>
>>> That's the thing: I can see that perhaps as an implementation detail,<br>
>>> but I can't actually see how the spec communicates that it's<br>
>>> absolutely necessary that the implementation know up-front what the<br>
>>> expected type is. A different perspective could come away with the<br>
>>> expectation that the ValueExtractor pass objects to the ValueReceiver<br>
>>> and *then* the implementation inspects the values received to<br>
>>> determine which constraints to apply.<br>
>><br>
>> It's the spirit of the spec that the declared type of a constrained<br>
>> element (property, parameter, etc., and now also container elements)<br>
>> is the basis for constraint validator resolution (see 5.7.4).<br>
><br>
> Fair enough. :)<br>
><br>
>><br>
>> It also mentions the possibility to create an annotation processor for<br>
>> checking that constraints are only put to elements as supported by<br>
>> available constraint validators ("rules can be statically checked").<br>
>><br>
>> Basing validator resolution on the received type as you suggest would<br>
>> deviate from this, which is why I think we shouldn't do it.<br>
>><br>
>>> The only place where this is<br>
>>> problematic is on the #keyedValue() calls, because you'd have to<br>
>>> inspect the nodeName to know which argument to apply constraints to.<br>
>><br>
>> I'm not sure I'm following on this one. Can you elaborate?<br>
><br>
> The spec says that #keyedValue() will be called twice per Map entry:<br>
> once per key and once per value, but the method signature includes<br>
> both the key and value along with the node name, so AFAICT you'd have<br>
> to consider whether the node name is "<map key>" or "<map value>" to<br>
> know which parameter was referenced. Or is the intent that the call<br>
> for the key repeat the key as both the key and value parameters? That<br>
> could make more sense, but I don't find the spec to be crystal clear<br>
> on that point if that is indeed the intent.<br>
><br>
> Matt<br>
><br>
>><br>
>>><br>
>>> Matt<br>
>>><br>
>>>> --Gunnar<br>
>>>><br>
>>>><br>
>>>> 2017-05-10 17:33 GMT+02:00 Matt Benson <<a href="mailto:mbenson@apache.org">mbenson@apache.org</a>>:<br>
>>>>> On Wed, May 10, 2017 at 9:17 AM, Gunnar Morling <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br>
>>>>>> 2017-05-10 3:59 GMT+02:00 Matt Benson <<a href="mailto:mbenson@apache.org">mbenson@apache.org</a>>:<br>
>>>>>>> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br>
>>>>>>>> Hi,<br>
>>>>>>>><br>
>>>>>>>> I'm curious about your take on supporting the types in ${subject}<br>
>>>>>>>> (BVAL-579 [1]).<br>
>>>>>>>><br>
>>>>>>>> They are non-generic wrappers for int, long and double. Should we<br>
>>>>>>>> support them with the numeric constraints such as @Min et al.? The<br>
>>>>>>>> easiest way to do so would be to just mandate support in the JavaDoc<br>
>>>>>>>> of the numeric constraint types.<br>
>>>>>>>><br>
>>>>>>>> The only thing I can see speaking against this is that we may migrate<br>
>>>>>>>> to an extractor-based approach in a future revision. Currently<br>
>>>>>>>> extractors cannot be used, as those types don't have any type<br>
>>>>>>>> parameter which could be extracted. But assuming we extend the<br>
>>>>>>>> extractor API in a future revision to deal with non-generic types,<br>
>>>>>>>> too, we could then rather mandate built-in extractors for those types.<br>
>>>>>>>> Which will allow to put *any* constraint applying to int also to<br>
>>>>>>>> OptionalInt.<br>
>>>>>>><br>
>>>>>>> Wait... the current draft of the spec still mentions implicit<br>
>>>>>>> unwrapping of containers. Is that not staying? Why can't we have e.g.<br>
>>>>>>> an extractor of OptionalInt to Integer, returning an absent value as<br>
>>>>>>> null?<br>
>>>>>><br>
>>>>>> Implicit unwrapping is staying, but value extraction cannot be used as<br>
>>>>>> is, as we'd lack a way for obtaining the wrapped type from a value<br>
>>>>>> extractor for a non-generic type:<br>
>>>>>><br>
>>>>>> OptionalIntExtractor implements ValueExtractor<@ExtractedValue<br>
>>>>>> OptionalInt> {<br>
>>>>>><br>
>>>>>> }<br>
>>>>>><br>
>>>>>> There is no type parameter/argument from which the wrapped type (int)<br>
>>>>>> could be obtained (which is needed for finding the right constraint<br>
>>>>>> validator). We could add an attribute to @ExtractedValue for such<br>
>>>>>> cases: @ExtractedValue(wrappedType=<wbr>int.class).<br>
>>>>>><br>
>>>>>> We could do this in a future revision or if we are confident about it<br>
>>>>>> in the Proposed Final draft. We are going to explore it in the RI (by<br>
>>>>>> using a separate annotation next to @ExtractedValue for the time<br>
>>>>>> being).<br>
>>>>><br>
>>>>> Okay, I hadn't investigated the JavaFX APIs and hadn't realized that<br>
>>>>> e.g. StringProperty and IntegerProperty did have a generic type<br>
>>>>> parameter up their hierarchy. I still don't know that I believe the<br>
>>>>> specification is fully consistent in this regard then, because section<br>
>>>>> 5.5.1 refers to these as "non-generic property types." I see that the<br>
>>>>> unwrapping for these types is intended to be fulfilled by<br>
>>>>> ValueExtractor<<wbr>ObservableValue<@<wbr>ExtractedValue T>>, but the<br>
>>>>> "non-generic property types" wording, to me, is suggestive of, and I<br>
>>>>> think this has been discussed, something like a ValueExtractor that:<br>
>>>>><br>
>>>>> * does *not* bear an @ExtractedValue annotation, and<br>
>>>>> * *must* be marked as @UnwrapByDefault<br>
>>>>><br>
>>>>> Then it seems an implementation would provide something like:<br>
>>>>><br>
>>>>> @UnwrapByDefault<br>
>>>>> public class OptionalIntExtractor implements ValueExtractor<OptionalInt> {<br>
>>>>> void extractValues(OptionalInt originalValue, ValueReceiver receiver) {<br>
>>>>> if (originalValue.isPresent()) {<br>
>>>>> receiver.value(null, originalValue.getAsInt());<br>
>>>>> }<br>
>>>>> }<br>
>>>>> }<br>
>>>>><br>
>>>>> This seems so simple that perhaps I am missing something; what is it? :)<br>
>>>>><br>
>>>>> Matt<br>
>>>>><br>
>>>>>><br>
>>>>>>><br>
>>>>>>> Matt<br>
>>>>>>><br>
>>>>>>>><br>
>>>>>>>> Should we do such change in a future revision, I don't think anything<br>
>>>>>>>> would change for users. Only providers would have to implement support<br>
>>>>>>>> for these types via extractors instead of dedicated constraint<br>
>>>>>>>> validators. I think such change is acceptable.<br>
>>>>>>>><br>
>>>>>>>> What do others think?<br>
>>>>>>>><br>
>>>>>>>> Thanks,<br>
>>>>>>>><br>
>>>>>>>> --Gunnar<br>
>>>>>>>><br>
>>>>>>>> [1] <a href="https://hibernate.atlassian.net/browse/BVAL-579" rel="noreferrer" target="_blank">https://hibernate.atlassian.<wbr>net/browse/BVAL-579</a><br>
>>>>>>>> ______________________________<wbr>_________________<br>
>>>>>>>> beanvalidation-dev mailing list<br>
>>>>>>>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
>>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
>>>>>>> ______________________________<wbr>_________________<br>
>>>>>>> beanvalidation-dev mailing list<br>
>>>>>>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
>>>>>> ______________________________<wbr>_________________<br>
>>>>>> beanvalidation-dev mailing list<br>
>>>>>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
>>>>> ______________________________<wbr>_________________<br>
>>>>> beanvalidation-dev mailing list<br>
>>>>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
>>>> ______________________________<wbr>_________________<br>
>>>> beanvalidation-dev mailing list<br>
>>>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
>>> ______________________________<wbr>_________________<br>
>>> beanvalidation-dev mailing list<br>
>>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
>> ______________________________<wbr>_________________<br>
>> beanvalidation-dev mailing list<br>
>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
> ______________________________<wbr>_________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
______________________________<wbr>_________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
</div></blockquote></div><br></div></div></div>