Lombok's received a JPA update a long time ago to make sure all this works well. A few caveats:
* You might want to use @EqualsAndHashCode(of="unid"). Opinions differ on how to model equals and hashCode methods for JPA objects. You should either exclude the primary key and use all other fields, or go only by primary key and never look at the rest. Lombok doesn't know you're using this class as a JPA model, so you need to specify this.
* By default, if a getX() method exists, whether lombok generated it or not, those will be used where relevant (equals, hashCode, toString, etc). That does mean that calling .toString() on a 'deep' structure will cause JPA to go haywire and query tons of objects. In practice you actually usually want this (because most db structures aren't that deep), but you can suppress it using doNotUseGetters=true.
retrospection is no issue at all; lombok is a compile-time only dependency. After your project has been compiled, it looks indistinguishable from code written out without the benefit of lombok to get rid of some boilerplate. getters and the like that lombok generated show up, equal in all ways to a hand-written one.