[bv-dev] Support for OptionalInt, OptionalLong and OptionalDouble

Gunnar Morling gunnar at hibernate.org
Wed May 10 10:17:59 EDT 2017

2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson at apache.org>:
> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Hi,
>> I'm curious about your take on supporting the types in ${subject}
>> (BVAL-579 [1]).
>> They are non-generic wrappers for int, long and double. Should we
>> support them with the numeric constraints such as @Min et al.? The
>> easiest way to do so would be to just mandate support in the JavaDoc
>> of the numeric constraint types.
>> The only thing I can see speaking against this is that we may migrate
>> to an extractor-based approach in a future revision. Currently
>> extractors cannot be used, as those types don't have any type
>> parameter which could be extracted. But assuming we extend the
>> extractor API in a future revision to deal with non-generic types,
>> too, we could then rather mandate built-in extractors for those types.
>> Which will allow to put *any* constraint applying to int also to
>> OptionalInt.
> Wait... the current draft of the spec still mentions implicit
> unwrapping of containers. Is that not staying? Why can't we have e.g.
> an extractor of OptionalInt to Integer, returning an absent value as
> null?

Implicit unwrapping is staying, but value extraction cannot be used as
is, as we'd lack a way for obtaining the wrapped type from a value
extractor for a non-generic type:

    OptionalIntExtractor implements ValueExtractor<@ExtractedValue
OptionalInt> {


There is no type parameter/argument from which the wrapped type (int)
could be obtained (which is needed for finding the right constraint
validator). We could add an attribute to @ExtractedValue for such
cases: @ExtractedValue(wrappedType=int.class).

We could do this in a future revision or if we are confident about it
in the Proposed Final draft. We are going to explore it in the RI (by
using a separate annotation next to @ExtractedValue for the time

> Matt
>> Should we do such change in a future revision, I don't think anything
>> would change for users. Only providers would have to implement support
>> for these types via extractors instead of dedicated constraint
>> validators. I think such change is acceptable.
>> What do others think?
>> Thanks,
>> --Gunnar
>> [1] https://hibernate.atlassian.net/browse/BVAL-579
>> _______________________________________________
>> 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

More information about the beanvalidation-dev mailing list