[bv-dev] Support for OptionalInt, OptionalLong and OptionalDouble
guillaume.smet at gmail.com
Wed May 17 11:44:03 EDT 2017
On Wed, May 17, 2017 at 3:33 PM, Gunnar Morling <gunnar at hibernate.org>
> > * Should we be really brave and rename or alias that member to value()?
> I thought about it, but value() reads poorly if other members are
> added down the road (I cannot think of any, though). But given that
> @ExtractedValue is only used by BV providers and a very few authors of
> custom extractors, I don't mind the few extra characters of type() for
> the sake of more explicitness.
> What do others think?
I don't think using value is a good idea. It might be clear now but won't
be if we decide to add another attribute later.
> > * Should we permit to specify as int.class and force the implementation
> > wrap? (I haven't tried it, and also haven't been awake very long, but I
> > can't think why it wouldn't work)
> Would there be any advantage to that? During constraint validator
> resolution (where this ends up being used), "primitive types are
> considered equivalent to their respective primitive wrapper class", so
> it shouldn't make a difference.
As for OptionalInt, I first used int.class for the ValueExtractor in HV but
then realized that the extracted type is indeed Integer.class as we extract
a null value if the value is not present.
In any case, HV boxes the primitive types automatically as HV only deals
with boxed types but this part is implementation specific.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the beanvalidation-dev