Skip to main content

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

  • From: michael keith <michael.keith@...>
  • To: jsr338-experts@...
  • Cc: Nicolas Seyvet <nicolas.seyvet@...>
  • Subject: [jsr338-experts] Re: proposal : @Entity on interfaces
  • Date: Mon, 12 Mar 2012 07:33:52 -0400
  • Organization: Oracle Corporation

Hi Nicolas,

See below.

On 12/03/2012 4:38 AM, Nicolas Seyvet wrote:
First, I would like to say that I find the proposal to be quite complex 
compared to the gains.  And I agree with Bernd and Michael.

However, I have to say that I did not understand the following comment:
"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."
What do you mean by aliasing?
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.

IMO, the biggest problem with JPA is that it is seen as being slow, and to 
encourage bad DB schema designs.
The performance question is more about perception than of specifying, I think. I'm not sure we can do much about that other than make sure we get the message out that persistence provider caching makes JPA tend to be faster than raw JDBC. On the bad schema side that is an argument for making sure we do a better job at warning developers not to use schema generation for production schemas.



-----Original Message-----
From: michael keith [mailto:michael.keith@...]
Sent: Sunday, March 11, 2012 6:27 PM
To: jsr338-experts@...
Cc: Bernd Müller
Subject: [jsr338-experts] Re: proposal : @Entity on interfaces

Let me first say that I don't like the model of interfaces on entities.
It is quite rarely requested and when it is, often the user wants multiple 
entities to be able to implement the same interface (e.g.
polymorphism w/o inheritance) to do something like this:

      public interface Employee { ... }
      @Entity public class BusEmployee implements Employee { ... }
      @Entity public class TrainEmployee implements Employee { ... }

and then in some entity:

      @Entity public class TranportationBureau {
           Employee empOfTheMonth;

The feature being proposed, if I understood it correctly, would not support 

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.

While I understood and sympathized with the reasons why Steve first suggested that the 
annotation be on the interface (to facilitate interface-to-single-entity enforcement) I 
tend to agree with Oliver and Bernd that it would make more sense to just add an 
"alias" element to the @Entity annotation and continue to apply it to the 
impl class. It would be the responsibility of the provider to disallow two entities 
from creating an alias to the same 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 ...
      public class EmployeeImpl implements Employee, Worker {
         // mappings ...


On 11/03/2012 12:23 PM, Bernd Müller wrote:
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?).


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 {

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 


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


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

Steve Ebersole 03/14/2012

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

michael keith 03/14/2012

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

Steve Ebersole 03/14/2012

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

Oliver Gierke 03/14/2012

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

Pinaki Poddar 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/13/2012

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

Pinaki Poddar 03/14/2012

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

Matthew Adams 03/14/2012

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

Nicolas Seyvet 03/12/2012

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

michael keith 03/12/2012

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

Linda DeMichiel 03/16/2012
Please Confirm