The problem I see with bundling the required constraints with HV is that this will never be exhaustive. We could provide constraints for the existing property types, but if a user e.g. adds her own BigIntegerProperty she'd again have to create a custom constraint.

Sure it is not exhaustive, but it would cover most cases and in the missing ones (probably just a few) you have to provide a custom constraint validator. I don't see that as an issue. Also, so far I am only aware of JavaFX as a true use case, aka we have un-parametrized classes whose values needs to be un-wrapped.

Regarding the JPA converter approach, I'm no big fan of referencing the converter type within the annotation, as it a) can become verbose when to be done for each usage

We can have a class level converter here as well. At least one knows what type of converter is applied. I actually like it.

and b) exposes an implementation type at the usage site which otherwise could be hidden from client code (e.g. being part of some internal package).

I don't see an issue in that

The auto-apply approach avoids this, but doesn't it have the same issues as the original approach? For the reader of the client code it is not apparent whether a constraint applies to the wrapper or the wrapped type (as he might not be aware of the converter), which you seemed to dislike.

Sure. I still dislike it. I was just saying that this is how it works. At least there is a choice, one can choose to either do it explicitly or implicitly (auto apply). This might be a middle ground.

but approach #2 also works for me; Configuring the unwrapping once on the class-level sounds good.

ok