Most Read This Week
Exposing J2EE Urban Myths
The reality behind the legends
By: Hani Suleiman
Jun. 3, 2004 12:00 AM
It has become fairly common these days when looking through blogs and various opinion pieces to hear a common cry: J2EE is a terrible, unwieldy, and cumbersome specification. While documentations from Sun and other vendors praise it, there is a lot of hostility and negativity toward it "down in the trenches," so to speak. These trenches, of course, are populated with technologists who are always on the lookout for the next big thing, and the rank and file folks who look up to the technologists for wisdom and guidance.
In my opinion, many of these complaints are misguided, spread through rumor mongering and anecdotal stories with little to no effort made to validate them or place them in context.
Without further ado, I present you with nine urban legends surrounding J2EE.
1. JNDI is awkward.
JNDI is tremendously useful when you consider the fact that many vendor implementations will throw in features like a global clustered JNDI tree. Locally scoped JNDI references also free you from having to embed resource absolute names in your source code. JNDI is also fairly straightforward and easy to use; the barrier to entry is low enough that it really does not qualify as an obstacle.
2. J2EE is difficult to develop in.
For example, there are still vendors who do not support rapid hot-deploy, exploded application directories and runtime configuration. When having to work with such servers, it's not surprising that developers are turned off of J2EE and complain that it takes 20 minutes to preview every EJB change. It doesn't help either that many of these vendors had terrible implementations that performed abysmally and forced the hapless user to jump through any number of fire hoops to get things done.
The deployment descriptor hell is also a valid argument, but tools like XDoclet and the upcoming J2EE 1.5 greatly ease this pain. Going further, there's a blossoming market of tool vendors who try to cater to "rank and file" developers. WebLogic Workshop, WSAD, and Sun's Java Enterprise Studio are all fine examples of vendors stepping in to try to cater to a certain kind of developer. It's also important to consider the target audience for J2EE. A simple rule of thumb applies: if it doesn't fit, don't use it. Many people forget the "enterprise" aspect of J2EE. Don't overassume your project's needs and, even more important, don't overassume your own skill level. J2EE is not a trivial spec; it attempts to tackle some very thorny issues that, contrary to what you might have been told, do not have a simple solution.
3. EJBs must be avoided at all costs.
When it comes to session beans and message-driven beans though, there are clear benefits and advantages that should not be ignored due to the frightful aura that the letters "EJB" seem to have floating around them. Don't be so eager to dismiss the benefits of a component architecture that frees you from having to worry about pooling, security, transactions, clustering, and distribution. Part of the blame, of course, has to be placed on examples such as the early Petstore examples that encouraged the use of EJBs when it very often just didn't make any sense; but more on that later.
4. J2EE is dead!
It's rare to find a financial institute that does not make extensive use of JMS. It's rare to find an enterprise that supports Java that has not purchased at least one J2EE application server. It's often more than a token purchase too, with important applications and services running on these servers. Also easy to forget is that a J2EE application will often not contain a single EJB (and be the better for it!). You're still using J2EE, and an application server will still provide your application with a lot of value-add. It's not a stigma to be bound to J2EE!
5. J2EE is unportable.
Realistically, you can have your applications be portable. Expecting it to be a trivial matter of dropping in the .ear file is naive and akin to expecting a Windows-developed Swing application to work flawlessly on an OS X machine without a single misplaced pixel. Sure it's doable once you do it a few times, but it takes knowledge of both Swing implementations to get it right.
To be fair to Sun, there have been a number of JSRs to help ease this problem. JSR-77 and JSR-88 (J2EE management and J2EE deployment, respectively) both attempt to reduce the vendor variance in these two areas.
Part of the problem also lies in the confusion about J2EE roles. While in reality it might be one developer who develops, assembles, and deploys an application, it pays to keep in mind that those three tasks are performed by different roles. A deployer, for example, would not know about the code that is being deployed, but would be able to spend the time and effort required to ensure the application is configured correctly to be deployed into a particular container and environment.
6. J2EE is expensive.
The hidden aspect of expense is the nonmonetary costs associated with it. Yes, you do need someone comfortable in a J2EE environment. For some of the free offerings, you certainly need to invest the time and effort it takes to get some of the more obscure features you're after to work. 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.
7. API "X" is too complex/unclear; it's easier to roll your own instead.
While it's enjoyable to tinker with various open source projects and play at integration with them, invest the time up front to use these features as provided by your application server. Yes, it's a lot less sexy; yes, it's a lot more boring. However, it will save time in both the short and long term, reduce your maintenance, and eliminate the "keeping up with the Jones'" aspect of tracking third-party sources. J2EE mandates many of these services, including but not limited to transaction management and connection pooling.
8. Petstore is a reference implementation.
Sun seems to have realized the faults with Petstore and has probably come to regret the early hacked-together versions. The new Adventure Builder blueprints application seems closer to a "real-world" solution in terms of implementation, I'm told. If you really want a Petstore kind of example, look beyond Sun's to the myriad of implementations used to demo various frameworks and tools. With very few exceptions, they're generally better written and make a lot more sense.
9. J2EE is useless without extra frameworks.
Not so! While many larger applications would see a huge benefit in committing to a particular framework (be it open source or otherwise), smaller ones often do not merit the extra learning curve, maintenance cost, and configuration nightmares associated with many of these frameworks. Be flexible, consider your needs, and pick an intelligent solution that fits the problem at hand. If any of these frameworks was a true "one size fits all" solution, it'd be part of the spec.
This in fact does seem to have happened, with the introduction of JavaServer Faces. Unfortunately while well intentioned, the specification is far from adequate in its current incarnation. I am told that the expert group is aware of these issues and is hard at work addressing them.
J2EE is an evolving spec, albeit at a slower pace than some would like. It has areas it will mature greatly in, and despite many assertions to the contrary, it's a mature platform backed by a strong specification and huge industry commitment. Investing in it might no longer seem to be glamorous or innovative, but that's the sign of a mature and well-established specification. The technologists might have moved on, but for the rest of us enterprise application developers, we have a powerful and compelling tool in our arsenal that's useful far more often than not.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads