The Joel on Software Discussion Group (CLOSED)

Can someone please explain where the portability is in J2EE when the reality is that each application server comes with its own specific set of deployment descriptors?

While I sympathize with your frustration, please note that you *should* only have to rewrite one thing: the deployment descriptor.

I meant "deployment descriptors" (with an "s").

In other words it is your beans and jsps and so forth that are portable.  To this extent J2EE portability is pretty good...not perfect, but pretty good.

BTW why would you call this a "Myth"?  This is no story that has been passed down through the generations or by word of mouth.  It is a pretty direct claim made by Sun.  It may be a "misnomer" to call it "portable".  Heck it might even be a lie but to call it a myth, not so sure your usage is correct.

Words have more than one usage, you should know. According to http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=myth usage #3 is "a person or thing having only an imaginary or unverifiable existence", and usage #2b is "an unfounded or false notion".

Simple anser: If you deviate from the Java spec by using functionality specific to your app server vendor, then you lose portability.

Complex answer:  The spec doesn't always do what you need, and you have to go outside of it.  If you plan for this and put your vendor-specific code behind an interface, there's a good chance that switching vendors will be much less painful than otherwise.

Of course, given the sheer cost of switching, how often do you anticipate it happening?

Switching J2EE containers happens more often than you'd think.

First there are version upgrades.  That may require rewriting code that depends on vendor-specific extensions.

Then there are J2EE vendors that either aren't very stable either as a company or with their long-term commitment to the J2EE platform. 

In addition, there are companies that are suffering with the opportunity cost of not switching vendors, because they have written their system to be so locked-in that they can't take advantage of moving to a more powerful or less expensive J2EE container.  Therefore it's not only important to worry about how often a switch will happen, but also how often you might *want* to switch but can't.

The J2EE - EJB spec is a specification gone wild. If you can, stay away from EJBs.

http://today.java.net/pub/a/today/2004/06/15/ejb3.html

I agree.  95% of the time, the task can be accomplished more easily and cleanly with servlets and plain old Java classes without any EJBs.

Its really no different than any other standard...Look at databases - if you don't use vendor specific features, you'll have very good portability.  If you design in lots of dependencies on T-SQL, PL/SQL, etc., portability is out the window.  Vendors will ALWAYS try to sneak in dependencies.  If you anticipate switching app servers, just stay away from non-standard functionality.

I should also add that I agree completely that J2EE is almost always overkill.

Most successful Java projects I've worked on have ignored 'ejbs' in favour of less convoluted & complicated approaches.

Have a look at the spring framework, and the accompanying book:

http://www.amazon.com/exec/obidos/ASIN/0764558315/ref=pd_ecc_rvi_2/104-0381565-1918334