JSR-299: Beating the Dead J2EE Horse




There are two central component models we use today: Spring POJOs and EJBs. With JSR-299 everything is a bean now. But, where’s the innovation? The JCP continues in conservation of what became a standard a decade ago.

HorseA week ago Rod compared Red Hat/JBoss and SpringSource. In the Open Source world that’s indeed a comparison between the component models EJB vs. Spring POJOs.

It is pretty clear for years now that even with EJB 3 the idea of a container which delivers everything to fulfill every non-functional requirement is a dead end. The ideas from a decade ago don’t work anymore. Maybe they never really worked, but nobody recognized it in those days. Thanks to Rod we have a good alternative today.

Most interesting with Rod’s blog post was a comment about JSR-299. Rod was asked what SpringSource will do to support “Web Beans”, what now is called “Java Contexts and Dependency Injection”. Nice. It’s official now, Spring is in standardization by the JCP.

Well, not really. JSR-299 takes all the old JCP standards of the last decade and tries to combine these with what Spring delivers for years. EJB is central part of all thoughts. No wonder with a JBoss guy as lead ;-) .

If you study the spec you recognize that we will get an EJB-lite container, but it is still an EJB container. Compare this to what SpringSource is doing with the Tomcat architecture today.

So, what is it all about? JSR-299 looks like an extension to EJB 3. So, it will help to get all the old stuff into a modern architecture concept. But, I expect that is will be cheaper to re-implement all the legacy stuff using Spring in the center and skip all the old and new EJB stuff around it.

BTW: The JSR-299 code examples show how horrible the code looks like if you have to use annotations excessively. But, the XML configuration doesn’t look smarter to me either.

  • Horse

    The horse on that picture doesn't look all that dead to me ;)

  • http://mbrainspace.blogspot.com/ matt

    Its time to use Grails man ;D Spring under the hood, no xml configuration to be seen, just a nice fresh BeanBuilder DSL.

  • rainwebs

    Rod recently did a presentation about the Tomcat stuff, the dm Server:

    http://www.infoq.com/presentations/dm-Server-Ro

  • Anonymous

    “Spring POJOs” ? POJOs were around *before* Spring, and POJO persistence similarly. Terming it “Spring + POJOs” would be more appropriate, because otherwise some of us would think you Spring people just want to claim credit for anything …

  • rainwebs

    Well, credits for efficient architectures would be enough to me ;-) . The POJO concept is not what is important here. But, how Spring is using it in comparison to EJB 3 and the influence on architecture, maintenance and the like. We also talk about Web container vs. EJB container. So, “Spring POJOs” is a term for the, if you so will, component model behind Spring.

  • rainwebs

    So, SpringSource and Google already suggested a JSR-330 for a pure, low-level DI standardization and all the EJB container guys had problems with it:

    http://tech.puredanger.com/2009/06/09/dependenc

  • rainwebs

    Very nice comparison of JSR-299 and Spring:

    http://blog.springsource.com/2009/06/03/red-hat

  • http://twitter.com/sferg sferg

    For a full example of JSR-299, take a look at the SubEtha maillist server. Because code examples are so small and generally contrived, they don't show how a technology is used in the real world. A full open source example like SubEtha is much better to get a feel for the technology.

  • rainwebs

    And a final comment to the final draft submission:

    http://blog.springsource.com/2009/06/03/red-hat