13 improvements for EJB
My last blog entry, "You can make EJB better" generated a lot of feedback from developers on Java.net and TheServerSide.com. I waited until Sunday night to review them so that people would have enough time to post their comments.
What struck me, after counting and grouping relevant posts, was that the developer community desperately desires a simpler programming model for EJB.
In particular developers appear to be most interested in the following:
1. Ditch CMP or make it simpler like Hibernate or JDO
2. Use a POJO programming model
3. Add support for Interceptors/filters/AOP.
4. Eliminate/Consolidate the component interfaces (remote, local and endpoint).
5. Make deployment descriptors more like XDoclet
6. Instance-level authentication/entitlement.
7. Replace the JNDI ENC with Dependency Injection (a.k.a. IoC).
8. Add a Mutable Application Level Context
9. Support development and testing outside the container system.
10. Define cluster-wide singletons for EJB.
11. Clearly specify and standardize class loading requirements.
12. Standardize the deployment directory structure for EJBs.
13. Support Inheritance.
Support for these top 13 features are shown in the order of preference. In other words, most people wanted number "1: Ditch CMP or simplify it like Hibernate/JDO". Of course these rankings are suspect because there were only 131 relevant "nominations" (out of 240+ postings). Still, this anecdotal pole provides us with some idea of what developers are looking for.
Some of the items can be grouped together to give more weight to a particular approach. For example, item 1, 2, 4, 7, 9 and 13 all seem to point at a CMP programming model that is more like Hibernate. Hibernate uses a POJO programming model with dependency injection (IoC) and is not dependent on client interfaces. In addition, Hibernate applications can be developed and tested without a container system. A tip of the hat to Galvin King and crew.
Other items were interesting but not surprising like asking for an XDoclet-like vendor-agnostic deployment processes. This is a big concern of mine since EJB isn't really portable in its current incarnation