J2EE Myths? Or Myth-understandings?
by Justin Gehtland
Related link: http://www.sys-con.com/story/?storyid=45077&DE=1
Hani Suleiman has written an article in this month's JDJ rebutting those in the industry who have taken a position against the overuse of J2EE. As one of the pack howling at that particular moon, I thought I'd respond. I'm one of those people that believes that code without tests isn't code, its hope. For me, testability is key. To be testable, my code has to be succinct, direct, and simple. Much (but not all) of the time, J2EE doesn't meet those criteria.
First, and foremost, let me say that Hani's assertion that most of the anti-J2EE opinion is "spread through rumor mongering and anecdotal stories with little to no effort made to validate them or place them in context" is a sweeping generalization about a wide variety of people, opinions and publications. I think the weight of his piece would have been greater without this needless swipe at the validity and professionalism of those who see things differently.
In our new book, "Better, Faster, Lighter Java", Bruce Tate and I argue that J2EE has negatively impacted the software development by inserting often needless complexity into our code, and being hostile to the tools that really drive quality, like automated unit and integration testing, for example. And, for 250+ pages, we tackle those issues and look at alternatives.
Now, on to his "myths":
1. JNDI is awkward.
Now, I don't know about you, but if I'm trying to argue against some position, I usually tackle the big items up front. If your biggest reason to avoid J2EE is that JNDI is awkward, then you probably haven't thought that much about your software. Essentially, your choices boil down to these:
a) couple directly to the binary image of your code at compile time
b) couple loosely to the binary through directory resolution
c) couple loosely to the binary through IoC frameworks
Frankly, as long as you avoid option a) as much as possible, then your other choices are just a matter of personal style. Given that, however, it is difficult to follow Hani's logic when he argues that JNDI is more useful when you count all the free googaws that the different vendors include for clustering JNDI. Those tools might be useful, but they don't make it any less "awkward".
2. J2EE is difficult to develop in.
This is my favorite point in the article. Hani admits that J2EE is unit-test-resistant and not particularly agile. However, he says that the blame should be placed with the vendors, not with the spec. That's like saying that hydrogen-filled airships are a decent idea, but its the guys who built the Hindenburg that are to blame. If all the tools available show the same resistence to TDD, then maybe the spec has something to do with it.
Hani later makes a point I totally agree with: J2EE isn't for everybody or every project, but it IS ideal for some. The important thing is to let common sense rule the day: if you will get more benefit than pain from using J2EE, then do it! Otherwise, find another path.
3. EJBs must be avoided at all costs.
Hani rightly points out that the lighter-weight EJBs (stateless session beans, for instance) can offer a lot of benefit without nearly the same cost as, say, entity beans. They are still test-resistant, though, and therefore the cost is still greater than some other options. Again, though, the rule of thumb is to make a real cost/benefit decision. If it comes out in your favor, do it.
4. J2EE is dead!
I just don't know where he got this. This sounds like a straw man to me. If J2EE was dead, why would there be so many of us out here beating the bushes for alternatives? There would be no need for a book like Better, Faster, Lighter Java if J2EE was gasping its last breath; we would just let it die. I mean, c'mon, have you seen the 3.0 spec?
5. J2EE is unportable.
Again, Hani blames the vendors for mandating their own custom deployment descriptors. I really don't get the distinction between the spec and the implementations OF the spec. This makes me wonder what Hani's motivation is. The spec is only as good as the implementations available. If they all make the same mistake, we, as developers, are stuck with the consequences, whether or not the spec mandates it. As it stands today, making an app portable between WebSphere, WebLogic and JBoss means spending a lot of time worrying about configuration and feature-creep that shouldn't be necessary.
6. J2EE is expensive.
I'm just not sure where he's going with the final line: "Do not neglect to factor in the cost of the time and effort you'd be wasting by going to a third-party library and spending hours reconfiguring it for every new application." This implies, seemingly, that you don't need to reconfigure J2EE for every new application, which is patently untrue (see his earlier point about deployment descriptor hell). If he didn't mean to imply that, but rather, to imply that other libraries have as many configuration problems as J2EE, then he's right. But they generally don't have the further costs, like a super-heavy container, intrusive requirements for your code, etc.
J2EE is expensive, whether or not you go with a commercial, open source, or commercial open source vendor. That expense comes in money, time, resources, and complexity. Just remember that expense is only half of cost/benefit analysis.
7. API X is too complex/unclear; it's easier to roll your own instead.
I don't disagree with his underlying point, which is that all the different implementations of J2EE provide a ton of services, some of which are trivial to set up. What I disagree with is his conflation of "using an open source project" with "rolling your own". Those are two entirely different concepts; if I choose to get my transactional management from a different framework, that doesn't mean I wrote it myself.
8. Petstore is a reference implementation.
Anybody who still believes this needs to be smacked down. I think the Petstore application has been dissected enough that people don't honestly use it as an example of anything, except maybe bad marketing.
9. J2EE is useless without extra frameworks.
Hani's right to say that "naked" J2EE still provides services that you wouldn't get with just plain POJOs and Tomcat, for instance. And, again, I say that if the cost is worth it (in money, time, and having a heavy container) then by all means, go with it. I'm just not sure where he's going by invoking JSF. Is this supposed to prove that really good frameworks become part of the spec? He says himself that there are issues with JSF that the committee is feverishly trying to work out. How does the committee rushing out a half-finished addition to the spec rebut the "urban myth" that J2EE is useless withot extra frameworks? To me, the JSF issue shows that J2EE is deficient on the presentation tier, and needs extra help, but that the addition to the spec doesn't yet solve the problem.
The opening paragraph of Hani's conclusion is, I think, as clear a presentation of my viewpoint as possible, and demonstrates that we agree on a common principle: don't blindly trust what some book author or CTO tells you. Be smart, use your brain, and figure out whether J2EE or Spring or Pico or POJOs or whatever solve your problems. And they use that solution. But be cognizant that J2EE often tries to solve problems you don't have, and you can often wind up writing more code to support your container than to solve your customer's problems.
not more J2EE == EJB crap
J2EE is far more than just EJB.
If I'd get $1 every time someone writes something under the assumption that EJB is somehow mandatory when using J2EE I'd never have to code again.
not more J2EE == EJB crap
If you got a $1 for every time someone assumes EJB is mandatory when using J2EE...you'd have just as much money after reading my blog as before it. I'm pretty certain I didn't SAY that, and I'm almost as certain that I didn't IMPLY it. In fact, I point out on multiple occasions that "naked" J2EE (meaning, no EJBs) has tons of available services to offer. My point, which I think I made clear, is that J2EE is often overkill for many of the projects it is employed on because it solves problems you often don't have.
Decent rebuttal, I don't feel too bad as you agree with just as much as you disagree with. Overall good points, and I'm glad that you present perfectly valid alternatives and counterpoints to many of my suggestions.