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 – you can't just drop an EJB JAR into most J2EE servers without adding some vendor specific deployment information. Actually this aligns nicely with the request that EJB define a standard directory structure for deployments similar to Web components.
The mutable application level context was a surprise for me. Standardization and specification of class loading behavior was not a surprise. Requests for instance-level authorization was also expected – it's something developers have been asking for since EJB 1.0.
I was delighted to see so many posts on this subject. Clearly people feel there is much to be done. I was less excited to see the thread wander off into Spring vs. JBoss vs. Mike Spille territory – but I found those posts interesting too.
Obviously, there are better mechanisms for measuring public opinion than a blog. Perhaps someone will take on the task of organizing a more accurate pole, but for me the information and posts were very informative. I read every one of them. I greatly appreciate the time and effort so many put into responding. Thank you.
I'm sharing these findings with the JSR 220 (EJB 3.0) Expert Group and expect your comments will generate a lot of discussion and a great deal of solid action by the group members. Keep an eye on JSR 220, eventually it will make it into public review at which time you'll have something solid to review and comment on. Your feedback is critical to the success of EJB.