EJB 3.0 – still trying to catch up to JDO and Hibernate

I was excited when the EJB EG released a second draft (EDR2) of the EJB 3.0 specification. It had been more than six months since the release of the first draft, which had left a lot to be desired when compared to Hibernate and JDO. Unfortunately, EJB 3.0 EDR2 is pretty disappointing because many of deficiencies of the first draft have still not been addressed. The one positive sign are numerous notes promising to address them in a future draft.

Inheritance issues

EJB 3.0 unlike EJB 2.x supports inheritance. One entity bean class can extend another and relationships and queries can be polymorphic. However, there is one significant restriction: entity beans must be concrete classes! In my opinion there is little point in supporting inheritance without supporting abstract classes and interfaces.

There is footnote that this will be addressed “at a later point” so hopefully that will be before EJB 3.0 is released.

Relationship problems

There are several relationship mapping issues with the EJB 3.0 EDR2.

·        No support for mapping lists and maps

·        Unidirectional one-to-many relationships

·        No support for collections of primitive types

No support for mapping lists and maps

EJB 3.0 collections can only be collections and sets. There is no support for mapping lists and maps. This is a pretty basic feature of JDO and Hibernate and is absolutely essential in an object/relational mapping framework. Fortunately, there is a note on page 13 that states that this limitation will be addressed in a future draft.

Unidirectional one-to-many relationships

Page 101 of the specification states that an EJB 3 implementation is not required to support unidirectional one-to-many relationships with a foreign key mapping. A portable application must either map them with a join table or use a bidirectional one-to-many relationship.

I really don’t understand this restriction because unidirectional one-to-many relationships are extremely common in object models and a foreign key mapping is a good way to map them.

For example, consider an Order-OrderLineItem relationship:

class Order {

  protected List<OrderLineItem>

  …

}

class OrderLineItem { … }

which should be mapped to this table structure:

CREATE TABLE FTGO_ORDER_LINE_ITEM
    ORDER_ID NUMBER(10)

    CONSTRAINT FTGO_ORDER_LINE_ITEM_ORDER_FK

        FOREIGN KEY(ORDER_ID)

        REFERENCES FTGO_ORDER(ORDER_ID)

There is no need for this to be a bidirectional relationship. Nor is there a need for it to use a join table.

This issue is a showstopper – I wouldn’t use a persistence framework that had this limitation.

No support for collections of primitive types

EJB 3.0 does not support collections of anything other than entity beans. You cannot have, for example, a collection of string or lists. Once again this is an essential feature of object/relational mapping framework. On page 13 there is a note saying that collections of other types will be supported in either a future draft or a later release.

This feature really needs to be in EJB 3.0. Imagine trying to persuade Java developers to remove this feature from the Java language.

This limitation is not a showstopper but it would certainly make me think twice about migrating from JDO/Hibernate to EJB 3.

Access control limitations

EJB 3.0 supports persisting both fields and properties. However, fields and accessor methods cannot be private (pages 12/13). Unlike JDO (which persists fields) and Hibernate (which persists fields and properties), they must either be public or protected. This restriction will force Java code to violate generally accepted programming guidelines that recommend that fields and methods are private unless there is a good reason for them not to be.

This limitation is not a showstopper but it would certainly make me think twice about migrating from JDO/Hibernate to EJB 3.

Summary

The EJB 3.0 specification is a significant improvement of EJB 2.0. However, progress has been slow and there is a long way to go before it is comparable with JDO and Hibernate. The 2nd draft promises that many limitations will be addressed in a later draft. However, three main areas of concern remain:

• Lack of support for persisting unidirectional one to many relationships with a foreign key mapping – a showstopper
• Lack of support for persisting collections of non-entity beans – extremely inconvenient and a barrier to migrating from JDO/Hibernate
• Lack of support for persisting private fields (especially) and methods – extremely inconvenient and a barrier to migrating from JDO/Hibernate

These are major obstacles to migrating JDO/Hibernate applications that I have recently developed to EJB 3.0.
I very much hope that the EJB expert group will address these concerns.

links: digg this    del.icio.us    technorati    reddit