The Myths
Read J2EE Urban Myths
- Myth: JNDI is awkward: +1 Hani nails this one, IMHO. JNDI is an awesome API and highly underutilized; in particular, I think every J2EE developer should at least play around with the example in-memory-based JNDI SPI Provider given with the JNDI Tutorial and look at ways to use JNDI to create a layer of indirection for lookup purposes. Particularly when combined with JNDI's federation capabilities, suddenly you have ways of identifying things in an entirely agnostic manner. This is powerful, much akin to COM Monikers or CORBA IORs.
- Myth: J2EE is difficult to develop in: -1/+1 It is difficult to develop in, mostly because J2EE's goal is to address high-scale enterprise systems. J2EE was never intended (at least, not at first) to be used in applications that won't go beyond departmental boundaries, despite the fact that this is where 70-80% of projects are. (Correspondingly, I've heard estimates that the large-scale enterprise apps, although rare, are where upwards of 70% of the money in J2EE is spent. Suddenly the reason why frameworks/lightweight containers like Spring or Nano/Pico-container are taking off makes more sense.) But Hani's point is well-taken: not everybody needs every facet of J2EE, such as needing EJB for every project, or JTA/XA transactions when working with a single Resource Manager.
- Myth: EJB must be avoided at all costs: +1 EJB is all about distributed transaction processing. If you need that, use EJB. If you don't (or if you don't know what it is), then stay away. 'Nuff said.
- Myth: J2EE is dead!: +1 Can't prove it by me, guys. I get about a 50/50 split in J2EE and .NET requests, so if J2EE is dead, so is .NET.
- Myth: J2EE is unportable: +1 Hani's right: "Expecting it to be a trivial matter of dropping in the .ear file is naive and akin to expecting a Windows-developed Swing app to work flawlessly on an OS/X machine without a single misplaced pixel." More importantly, achieving J2EE-portable (what I prefer to call "vendor-neutral") code is something that you should openly decide you need, not decide by default, since you run the risk of forfeiting useful vendor optimizations when you do.
- Myth: J2EE is expensive: +1 Again, Hani hits this one on the head when he says, "The hidden aspect of expense is the nonmonetary costs associated with it.", such as finding someone who's "comfortable in a J2EE environment". In fact, I'd argue that for any J2EE project to truly succeed, you need someone who's more than just comfortable in it, you need someone who's achieved Master status to lead the team--which is probably J2EE's biggest weakness.
- Myth: API "X" is too complex/unclear; it's easier to roll your own instead: +1/-1 Too many people are trying to "roll your own" lots of things, but sometimes there are situations where it's easier/simpler/more reliable to roll your own "X", so long as you're comfortable with the API in question--and in this sense, Hani's exactly right. Rolling your own "X" because you don't understand "X" is clearly a Bad Thing; rolling your own "X" because you find flaws with "X" and need to clear them up or do things "X" doesn't let you do or because "X" is simply too awkward and clumsy for what you need isn't intrinsically bad, so long as you can explain to another programmer exactly how it is that "X" works. If you can't, then rolling your own is probably an Even Worse Idea. For my money, the list of Banned Roll-Your-Own Technology "X" ideas includes object/relational layers (in fact, I'm not even a fan of the ones that are out there right now, either), connection pools, object pools (which are a terrible idea except under very specific circumstances), more MVC-based web frameworks, JDBC library wrappers ("to hide away the SQLExceptions"), and any attempt to write your own Spring/Nano/Pico-like lightweight container.
- Myth: Petstore is a reference implementation: -1 Sorry, Hani, but Petstore was a reference implementation when it was first released. It was clearly billed as a "right" way of building J2EE apps, and the fact that it did all the things that we today see as terrible ideas is clear indication that Sun didn't quite understand yet how to use their own technology--which is no shameful admission, since it usually takes 5 years or so to "figure out" any technology (even those that are moderately complex). Just imagine all the fun the .NET world will have in the next three years or so....
- Myth: J2EE is useless without extra frameworks: +1 There's a tendency amongst J2EE folks to want to make use of every latest framework or toolkit or aspect-oriented-whatever, and Heaven forbid you actually just sit down and use the J2EE functionality out of the box. In fact, the tendency of any J2EE environment is to want to create layers on top of layers on top of layers on top of layers.... "just in case we want to change anything". Folks, if you need to change something, you can rewrite the code later--there's no shame in that. There is, however, major shame in introducing so much indirection that it takes your system twelve days to respond to a single HTTP request.