Will J2EE change its face?

Rod Johnson, the driving force behind the Spring Framework and CTO of Interface 21, outlined in one of his articles the points that would guide his group’s approach to working on the Java EE 6 standard. There’s no point repeating them here. You can read them yourselves.

From what Rod Johnson has said so far, you get the sense that he’d like to bring the ideas and spirit behind Spring into J2EE 6 as well. I’ll probably be repeating myself, but I count the following among J2EE’s biggest mistakes and shortcomings.

• Complexity and limited flexibility, making simple things complicated and trying to make one size fit all
• Virtually no integration between the component model (EJB) and the web model (JSF)
• Attempts to standardize immature technologies
• Hardly any room for extensibility
• Very slow adoption (the gap between the specification and production implementations)

Anyone who says these aren’t problems is as out of touch as the authors of the original J2EE specifications, or is looking after their own interests, as application server vendors do. The expert group itself has said it intends to address the problems. See J2EE 6 — A step in the right direction. If they pull it off, it will mean nothing less than J2EE changing its face for good.

I’m placing my biggest hopes in the inclusion of OSGi and Web Beans. At least for managing and packaging classes, OSGi offers a much more flexible model than the existing J2EE class-loader hierarchy. Unfortunately, the current class-loader behavior of application servers, and the fact that the specification never allowed for something “OSGi-like,” make it problematic, to put it mildly, to deploy an application that uses OSGi. Web Beans draw heavily on JBoss Seam and are meant to narrow the gap between the component model (EJB) and the web model (JSF).