This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
For small applications, you're certainly right and in that case, I couldn't agree w/ you more.
However things change when you start talking about more than just trivial applications that span a few database tables. No matter how much work you do to create reusable code to help map objects to tables (believe me, I've written that code and been down that road) - you still have to do this manually for each of your domain classes...you have to write the CRUD SQL...and all of this coding takes time and testing.
Now, put something like Hibernate into the picture...no more SQL (hopefully), no more manually mapping each field of the table to a particular class, no more hours spent hunting down bugs from changing a field, then having to change each query that touches it, each mapping class, etc.
At least, that is the dream. I think Hibernate solves 50% of these problems and creates a whole slew of new ones to consider that would make it arguable as to whether or not you're really saving any time or complexity. Even now, after a few months...I'm finding new problems regularly enough to consider waiting for a new release before using it again.
Personally I prefer a solution like db4o (www.db4o.com) - a pure object database. A lot of developers won't agree that this is feasible and will point out that ODBMS hasn't really taken off in the marketplace. I can make just as many arguements as to why it's the best solution...and I believe it is.
For example...I wrote a simple Blog application using JDBC. I did all of the mapping manually and it worked well...but it added up to several-thousand lines of code for a simple project. I refactored that using Hibernate and replaced about 25% of the code (if you don't count the slew of XML config files I had to create in the place of Java code.) Hibernate was complicated to learn and not simple for someone familiar w/ n-tier web application design to quickly pick up. However, I got it working and learned to deal w/ the issues that arose w/ using Hibernate.
Then, I refactored yet again using db4o. I eliminated about 30% of the existing code at that point and was able to complete it in about three days. It is *many* times faster and I can now concentrate on adding features instead of debugging for subtle problems and coding around inflexibilities.
No more JDBC, no more sql, no more ORM complexity, no more fine-tuning like crazy to squeeze out little performance gains because of database connectivity.
The only times I've not used an ORM layer (i.e. straight JDBC) for anything more than a prototype app I've ended up writing a tool to generate the JDBC code, since it so quickly becomes a major job maintaining an ever growing layer of "nuts and bolts" JDBC stuff. Since the advent of good open source ORM tools, I haven't looked back.
To get an indication of why ORM's are so useful, take a look at the source code for all the Dialects Hibernate supports. These comprise thousands and thousands of lines of code that you would otherwise have to write yourself if you didn't use an ORM. And all they do is handle the subtle differences between how databases understand SQL (or a varient thereof).
A good ORM is not too complex (though it might feel that way when first approached) since its job is actually quick simple. But it is worth the effort to use one.