Sorry, most of the pertinent discussion actually happened on IRC, not
the email list. Just for completeness:
http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/2012/%23hibernate-dev.2012-01-26.log.html
On 03/12/2012 09:53 AM, Steve Ebersole wrote:
> JPA is about mapping concrete classes to relational databases. I never
> claimed otherwise. If that was the mis-assumption from suggesting
> @Entity be allowed on interfaces, I apologize for not being more clear.
>
> No, as Oliver points out, the proposal is more about aliasing. There is
> a thread on the Hibernate developer list[1] that discuss this in detail.
> Basically I think that trends in development prefer interface-driven
> design. Whether you agree with that or not for a JPA model is not really
> the discussion. The proposal is more about working with that more
> seamlessly.
>
> Personally I think this should be a straight-up re-aliasing;
> one-for-one. That and another more esoteric reason is what led me to
> propose @Entity on the interface itself, with a attribute pointing to
> the class being physically mapped. But I also see the benefit in
> Oliver's suggestion to having that "link" on the entity *class*. This is
> a point we specifically discussed on that Hibernate developer
> discussion. In retrospect, I think the approach Oliver mentions is
> better approach. It allows the jar separation he mentions, plus other
> benefits.
>
> [1] http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007627.html
>
> On 03/12/2012 07:08 AM, Oliver Gierke wrote:
>> +1 on Mike's statement here. My initial intention (and I think Steve's
>> as well) was what Mike explained in his other email: aliasing access
>> to a JPA entity through an interface for the purpose of being able to
>> separate code and e.g. have the interfaces in one JAR and the
>> implementation class in another one.
>>
>>> The key part of what was being proposed (at least how I interpreted the
>>> feature, Steve can correct me if I misinterpreted) was the ability to
>>> "alias" an entity class. This just means that one might be able register
>>> an entity class in the providers entity list keyed not only by the
>>> concrete entity class, but also an (or more than one?) interface, so
>>> that when the provider encounters that interface it gets loaded/saved by
>>> the provider as the concrete entity class.
>>
>>
>> No additional metadata, simply metadata aliasing. I think ideas like
>> this originate from the trend for developers to build rich domain
>> models, follow Domain Driven Design and don't treat domain classes as
>> pure data containers. Although one might argue this is not what the
>> JPA spec is about I think we should make sure we don't get in the way
>> when following this approach so that devs don't get into a "I can't do
>> this because JPA can't deal with it" situation from a class' design
>> perspective.
>>
>> Looking at the extended proposal @Entity on an interface feels a bit
>> weird as well, at least given the current semantics in the spec. I
>> could imagine an @EntityAlias though with the following usage model:
>>
>> %<----------------------------------
>> @EntityAlias
>> public interface Person {
>>
>> }
>>
>> @Entity
>> public class MyPerson implements Person {
>>
>> }
>> %<----------------------------------
>>
>> Not sure I favor this over explicitly listing the alias interfaces on
>> the @Entity (e.g. @Entity(typeAlias = { Person.class }) as with the
>> original proposal you could implement the interface with a second
>> class without creating the conflict of two implementation classes
>> using the interface as alias.
>>
>> Mike Keith wrote:
>>
>>> Having said that, if we think that aliasing is one of those things that
>>> could stop large companies from using JPA we might decide to close our
>>> eyes, hold our noses and go ahead and add some kind of support.
>>
>>
>> Could you elaborate on that? I don't quite get why this feature should
>> stop companies from using JPA.
>>
>>> @Entity(alias=Employee.class)
>>> public class EmployeeImpl implements Employee {
>>> // mappings ...
>>> }
>>>
>>> Where does one draw the line? Would we assume that a single alias is
>>> enough and that an entity would not be allowed to specify a Set? For
>>> example, that we would not need to support something like:
>>>
>>> @Entity(aliases={Employee.class, Worker.class}) ... or ...
>>> @Entity(aliasInterfaces=true)
>>> public class EmployeeImpl implements Employee, Worker {
>>> // mappings ...
>>> }
>>
>> The latter doesn't seem to complicate things, does it? At least given
>> the assumption there has to be a single implementation class to be
>> selected to back the type alias, right?
>>
>> Cheers,
>> Ollie
>>