[bv-dev] Value extraction - how to obtain the validated type for non-generic wrappers?

[Gunnar Morling]

2017-03-23 16:39 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> It’s interesting.
> How does that work when Ceylon decides to go for a native support instead of the extraction model? Can they keep a mix?
> I.e. do we prioritize the actual ConstraintViolation<Min,ceylon.language.Integer> over a ValueExtractor<@ExtractedValue ceylon.language.Integer> + ConstraintViolation<Min,Integer>
> I see that you used @UnwrapByDefault, my concern comes from that.

Right, the extractor would be preferred. So Ceylon would have to
provide either the extractor or the dedicated constraint validator.

A related case is Java's OptionalInt, OptionalLong and OptionalDouble.
It'd be nice if all existing constraints for int/long/double would
automatically be applied to them.

Given the point in time I think though I'd rather mandate that the
built-in numeric constraints are supported for those, too, and first
explore the handling of non-generic containers in the RI. In a future
revision this requirement towards BV implementations could be changed
into mandatory value extractors for these types, without breaking user
code.

WDYT?

>
> BTW it will mandate nested extractor support.
>
>> On 23 Mar 2017, at 03:52, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Hi,
>>
>> I've received some very interesting feedback on the value extraction
>> proposal from our team working on the Ceylon language.
>>
>> Ceylon does not only have its own collection framework, but also
>> custom numeric wrappers, e.g. ceylon.language.Integer. Of course it'd
>> be desirable to be able to apply existing constraints such as @Min to
>> these. Instead of creating custom implementations such as
>> ConstraintValidator<Min, ceylon.language.Integer> we thought value
>> extractors could be used to enable all the existing constraints and
>> validators:
>>
>>    @UnwrapByDefault
>>    public class IntegerValueExtractor implements
>>                 ValueExtractor<@ExtractedValue ceylon.language.Integer> {
>>
>>        public void extractValues(
>>            ceylon.language.Integer originalValue, ValueReceiver receiver) {
>>
>>            receiver.value( null, originalValue.getValue() );
>>       }
>>    }
>>
>> The problem only is that BV cannot derive the wrapped type
>> (java.lang.Integer) from the annotated extracted value type
>> (ceylon.language.Integer) in this case, as it isn't generic.
>>
>> My question is: should we support this use case? If so, how? One
>> option I can see is allowing to specify the wrapped type explicitly if
>> the wrapper is non-generic:
>>
>>    public class IntegerValueExtractor implements
>>        ValueExtractor<@ExtractedValue(type=int.class)
>> ceylon.language.Integer> {
>>        ...
>>    }
>>
>> type() would have a default value of void.class, so it doesn't have to
>> be specified if the wrapped type can be derived.
>>
>> We also could decide to not support, requiring integrators such as
>> Ceylon to declare their own constraint validators for BV built-in
>> constraints, but obviously that'd fall short when it comes to
>> 3rd-party custom constraints for basic Java datatypes.
>>
>> Thoughts?
>>
>> --Gunnar
>> _______________________________________________
>> 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