This past week I started adding a new set of features to a legacy EJB 2.x application that I wrote circa-2002 and which follows Core J2EE Patterns to the letter. In a nutshell, that means there are Struts Actions which call Business Delegates that delegate to Stateless Session Beans which in turn execute straight "Fast-Lane Reader" JDBC or talk to CMP Entity Beans with local interfaces. Whew! This is the first time in about three years that any new features have been requested for this application. Up until now it has been humming along nicely, though trying to migrate it to WebLogic 8.1 from WebLogic 7.0 was somewhat of a challenge with changed WebLogic deployment descriptor settings I needed to track down.

The new features are relatively minor, or at least they would be in a modern architecture using Spring, Hibernate, a more modern web framework than Struts, AJAX, etc. To add the new features as rapidly as possible - a week or two at most is what I was aiming for - I decided to stick to the existing architecture. The main reason I chose this path was internal consistency within the application, so there was not a mishmash of legacy and modern technologies which would undoubtedly make maintenance more difficult. The secondary reason is that I thought it would actually be faster to stick to the way it had originally been implemented, rather than try to introduce a bunch of new technologies that facilitate faster development. Whether it would have been faster to integrate newer technologies I'll never know as I am committed at this point and have implemented a fair chunk of the new features in the past few days.

But, what I've learned is just how slow and tedious using the legacy EJB 2.x architecture really is, especially now that I've done several projects using Spring, Hibernate, et. al. After all, I just want to implement a simple JDBC query and display it in a browser, right? Not with EJB 2.x! Dealing with JNDI lookups manually, obtaining and handling JDBC connections, rollbacks in Stateless Session Beans on exceptions, writing Business Delegates that essentially do nothing at all but "hide" RemoteExceptions and delegate to Session Beans and more, has really made me appreciate just how much easier things have become with the more lightweight frameworks supporting the Buzzwords-du-Jour such as IoC, Dependency Injection, Transparent Persistence, etc. This includes Spring, Hibernate, the new Java Persistence API (JPA), Ruby on Rails, and a lot more.

I now know exactly why it took me nine months to write the original version of this application back in 2002 using EJB 2.x technology. For a project of similar size and scope I'd estimate no more than three months and maybe less using modern frameworks in 2006. Probably even less if you are among those lucky enough to use Rails. So what's the point of all this? I think mainly that there has been a consistent progression towards lighter weight frameworks that just let you get your job done in a more efficient and less invasive manner. And also why DRY always results in faster development, more maintainable code, and more fun developing.