Skip to main content

[jsr338-experts] Re: proposal : @Entity on interfaces

  • From: Bernd Müller <bernd.mueller@...>
  • To: jsr338-experts@...
  • Subject: [jsr338-experts] Re: proposal : @Entity on interfaces
  • Date: Sun, 11 Mar 2012 17:23:27 +0100

I think, this would make many things more complex to specify in a
consistent way.

In general, interfaces are a way to describe contracts in an
implementation independent way and therefore should be as abstract
as possible. JPA is a mapping between VM-objects and databases and
therefore as close as possible to the implementation level.
Here I see some problems from a conceptual point of view.

I also see many problems in practice. How to map fields in classes,
which are eventually named different than the annotated getter in the
interface? How to map interface hierarchies with multiple super
interfaces to eventually DIFFERENT class hierarchies with
single inheritance? There are more, I think.

We have to balance if it's worth to get such new problems which have to
be resolved in the spec and on the other hand the benefit is less
typing (how much?).


Bernd


Am 09.03.2012 19:04, schrieb Steve Ebersole:
> I'd like to propose that JPA 2.1 allow @Entity on Java interfaces not
> just classes.  The main reason is typing in spec contracts.  For domain
> models that leverage interfaces, it is usually desirable to deal with
> the interfaces over the implementation classes.  For example, such
> applications would generally prefer to attempt to load or get a
> reference to an instance based on the interface name as opposed to the
> class name.  E.g.
> 
> public interface Person {
>     ...
> }
> 
> @Entity
> public class PersonImpl implements Person {
>     ...
> }
> 
> EntityManager em = ...;
> Person p = em.find( Person.class, theKey );
> 
> But this does not work today in a portable manner.  To work in the most
> portable manner, I think the @Entity annotated interface also would need
> to name the "persistent implementation class":
> 
> @Entity( impl = PersonImpl.class )
> public interface Person {
>     ...
> }
> 
> public class PersonImpl implements Person {
>     ...
> }
> 
> It could be up to each provider whether or not to support @Entity on an
> interface that did not specify a "persistent implementation class".
> 
> Another way to look at this is as basically "aliasing" the entity type
> metadata using the interface name instead of the implementation class name.
> 
> -Steve




[jsr338-experts] proposal : @Entity on interfaces

Steve Ebersole 03/09/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Oliver Gierke 03/09/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Steve Ebersole 03/09/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Bernd Müller 03/11/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

michael keith 03/11/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Matthew Adams 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

michael keith 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Oliver Gierke 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Werner Keil 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

michael keith 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Oliver Gierke 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Steve Ebersole 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

Steve Ebersole 03/12/2012

[jsr338-experts] Re: proposal : @Entity on interfaces

michael keith 03/14/2012
 
 
Close
loading
Please Confirm
Close