Re: [hibernate-dev] Possibly interesting use of Jandex

2014-03-11 17:45 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > On 11 March 2014 10:59, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > > 2014-03-09 18:31 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > > > > @Entity > >> interface Employee { > >> ... > >> } > >> > >> 2) We'd dynamically generate a class to back this. This generated > >> class > >> can contain many of the performance tweaks we've been developing via > >> bytecode extensions (inline dirty-checking, "entity entry" info, etc). > >> > > > > In which situation would one make use of this? This seems to encourage > > "anemic data models", i.e. entities which are just data holders but > > don't > > contain any business logic. Often it's very useful though to add logic > > dealing with an entity's state to the entity type itself. > > I actually see this going in the opposite direction. Allowing to move > all the mapping stuff to a different interface would encourage me to > think of the implementation as something which can include code, and I > could even have multiple types having different *implementations* if > the non-persistent methods. > > It would also fight usage of inheritance, which is common among JPA > users and something that I'd gladly avoid. > > Would be a very nice to have to avoid anemic data models. I'm not following. The idea in 2) (which I was referring to) was to *generate* the implementation class. How does a custom implementation play into this? Are you referring to alternative 1) maybe?