Excellent comments. Let me see if I can provide a counter argument, in the spirit of the article.
Note this article is about EJB, and not J2EE. I actually think that there's a whole lot about J2EE to like. I especially like the way that you can scale your complexity. If you want to use messaging, you can...otherwise, just leave it behind. Not so with the container.
I do think that there are real differences between proposed EJB and Spring. They all relate to productivity:
- Metadata strategy. I like the Spring strategy better. It does not bind you to the container. Improved flexibility usually leads to better productivity down the road.
- Pragmatic exception management. It's much cleaner in Spring. You can do as much with less effort.
- Elegant facades. Check out a Hibernate facade in pet clinic, one of the Spring examples. You'll be able to do the same with JDO.
- The packaging. Spring makes it easier to leave behind parts of the framework that don't fit.
And I could go on and on. So it's not all about dependency injection. It's about pragmatic and simplified decisions, that the authors of Spring made over and over and over.
I've bet my career on Java. I'm just not willing to tie it to EJB any more. In short, I don't want to eat the elephant. There are great elephant hunters out there. And now, there will be a few more elephants for them. |
java.net RSS Feeds
