I in particular don't want to introduce something now which is sub optimal in conjunction with the Java 8 work we are going to start soon.

That's a very good point which we need to keep in mind. Still a solution working with older Java versions will be beneficial for users for quite a long time. Also JavaFX won't be able to take advantage of the type parameter solution.

Regarding JavaFX, how many different types are we talking about? Would it make sense to bundle the required constraint validators as part of HV?

The API docs has a complete list of Property subtypes.

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. Thus I think a generic solution which automatically enables to apply all existing constraints/validators makes more sense.

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 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).

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. Personally I wouldn't mind to always unwrap values (which makes things deterministic), but approach #2 also works for me; Configuring the unwrapping once on the class-level sounds good.