The code you have to write under CMP is *significantly* less than the code
you have to write under BMP (bean managed persistence).  But code size is
not the only thing to consider...

The entity EJB CMP engine requires knowledge of the application server in
which your entity EJBs are deployed.  That's the biggest problem.  I'll
now elaborate...

A big selling point of J2EE is portability between application servers.
In other words, the website (JSPs) you develop can be packaged in such a
way that the .WAR file that contains your web application can be deployed
into any J2EE environment that supports web applications.  Tomcat,
WebLogic, WebSphere, IPlanet, etc - it doesn't matter what environment you
choose to deploy your web application into.  As long as it supports J2EE
(the web application portion), you are good to go.

Enterprise applications (which consist of EJBs and web applications) can
break this purity if they use CMP.  Since CMP is a part of the EJB
framework that an application server implements, the CMP engine you choose
must be deployed outside of your application - it must be deployed
alongside your application server.

Why this is potentially disasterous is vendor lock-in, which is what J2EE
was developed to avoid.  You can develop your application using Program X
(TopLink for example) as your CMP engine.  You use Program X to map the
fields in your entity EJBs to fields in a relational database.  It now
comes time to deploy your EJB.  Instead of cleanly dropping your
Enterprise Application .ear file into your application server, you must
now modify the environment in which your application server executes so
that it has visibility to the CMP engine you used to map your entity EJBs.

This requires a manual step.  And what happens if your CMP engine does not
support lots of different application servers?  For example, if you use
TopLink, you can only use version 7.0 of WebLogic Server.  Or, you can use
a particular version of WebSphere.  But, you cannot use JBoss.  And you
can't use any other application server out there.  Your dependency on your
CMP engine limits you to the application servers your CMP engine is
compatible with.

In lots of cases this sucks.  Especially with TopLink (it's kept us on
Java 1.3 for *years* now).

With BMP you're in a different boat.  With BMP, your entity bean code
directly accesses the BMP libraries for persistence.  Under BMP, you can
implement your persistence however you want (you can use JDBC directly to
persist your objects, or you could use some other type of middleware
mapping tool to do it for you).  Because your bean uses a library (or
JDBC) as opposed to the application using a library, the library can be
packaged *WITH YOUR APPLICATION* thus making it portable across
application servers.  In other words, if you make your entity EJBs BMP,
and use JDBC for persistence, you can deploy them in pretty much any
application server you wish: WebLogic, WebSphere, JBoss - whatever.  It
doesn't matter.  And it's clean because you don't have to manipulate the
environment in which the application server operates in order to enable a
particular library.

So the simple answer is yes, CMP makes your life easier from a coding
perspective.  It's true that you get to write 0 code to enable CMP.  But,
from an overall cost/managment perspective, CMP still has a long way to
go.  BMP offers lots of benefits, and doesn't come at a steep cost.
Definitely consider BMP for your project.

-c