good question. JDBC seems pretty darn easy to me. why hibernate?

Horses for courses.  If you have a special requirement, like "we already
bought weblogic 8.0, and it is running on our server.  You have to use
it.", then your decision is made.  Otherwise, look at the cost of
implementation, the heft of learning, and what your long term goals are.

If you write the sql yourself, which JDBC requires you to do, then
switching to a different dbms can be a pain.  Something like HQL may
(not will) wrap that kind of db problem for you.

EJB3 is pretty close to hibernate in many ways, so I will assume you are
asking about 2.1.  From what we have seen, many app servers happily
implement code to make EJBs work well, and be monitored.  They may not
implement similar monitoring features for Hibernate.  Thus, you need to
check your specific app server.  Given that the jboss group now funds
hibernate development, I suspect that this is not an issue for JBoss.

From where I sit, I would probably go the Hibernate route for now, as it
can be used with all sorts of deployment strategies, including
standalone apps. EJB requires an EJB container.

Scott

Item 1. In today's world of editors that make your getters and setters
item 1 is a non issue.

Item 2. While having less code is an advantage, when you buy into
Hibernate you're not just replacing JDBC, you are investing in a
persistence oriented software system. While Hibernate provides caching
and can allow your application to share millions of objects across
servers, it does not have the flexibility of JDBC. In JDBC when you do
an update it's straightforward (although tedious) to write the code so
that only modified columns are updated. With Hibernate you're locked
into all or nothing.

Item 3. So what's the problem?

Item 4. EJB and Hibernate are mutually exclusive technologies, not
competing technologies.

Item 5.  If you are buy into an EJB solution there's probably some
feature of EJB that makes using it a good option. Again, with today's
editors building templates for you special names aren't an issue.

Other items . EJB and Hibernate are not competing technologies they are
mutually exclusive.

In applications where I do a lot of outter join select statements JDBC
leaves Hibernate in the dust.
While it's true that you can get a Connection in Hibernate and then use
JDBC, it's begs the question - then why use Hibernate in the first
place.

Also, if you use Hibernate eventually, as a programmer, you have to get
familiar with it's caching strategies and how it handles instanciation.
I've seen instances where a HQL statement instanciated 1000 objects
which then instanciated 5000 other objects and basically brought the
system to a crawl. Eventually the HQL had to be dropped. But not before
making Hibernate instanciate the objects separetely

BTW, JDBC solutions can be made easy to read.

Spring's JDBC framework makes code easy to read and manages your
connections. It also allows you to build SQL transactions across
multiple data fetches.

Certainly, I don't want to depend on any 3rd party APIs, sticking to
standard Sun stuff has many advantages.

Now with EJB 3, there is also the Java Persistence API which is POJO
based and it can be used with or without EJBs. I'm finding the case of
Hibernate even less compelling!

Below you compare Hibernate to EJB but one is a persistence API the
other a distributed component API. *Two very different animals*.

And previously rather than Hibernate 2 I had written my own db/jdbc/dao
layer, that code was re-used in many projects. It wasn't a lot of code
either amd I think that was less work than learning Hibernate.

Then for each POJO I just needed to write a small amount Java code
(save/load) which is about the same amount of work as that required for
those Hibernate XML files.

(SNIP - we need to compare Hibernate to Java Persistence API not to EJB
3 ;-)

I recommend Sun's FAQ for EJB 3 and the new Java Persistence API at
their web site. See glassfish while you're there.

Cheers.