On Wed, May 17, 2017 at 3:33 PM, Gunnar Morling <gunnar@hibernate.org> wrote:
> * 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 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)

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.