Post-2003 if you write your own ORM tools you need to take a step back and take a long hard look at yourself and what you are building. Really!
Between Hibernate, iBatis and Toplink - right there you've got three great alternatives that are
1) Heavily in use - thus debugged quite a bit
2) Have had performance improvements
3) Have books and good online help (the "google factor")
4) Have tons of great features including caching (even across clustered app servers), lazy loading etc.
but best of all you can hire people off the street who already know this stuff rather than have to train them on your proprietary protocol.
For full disclosure . . . in 2005 I had to architect an application that talked to a legacy Sybase database and a new Oracle database. For Oracle we used TopLink (which was fabulous!). For Sybase we rolled our own- why? Because the legacy Sybase database was interfaced to by Temp tables. That is you couldn't update tables directly - you had to put all your updates in a temp table and call a stored procedure which would validate the updates and either pass them on or reject them. Gak! :-(
I debated Hibernate vs. iBatis and frankly, although iBatis was close, I was under the gun and I knew I could generate most of the code pretty easily. That said I wasn't happy with the result - although the generated code was fairly easy to follow and debug, it was a fair answer to a bad situation. Fortunately we used some good layering so that the "true" business object layers knew nothing about how the DAOs were operating.
That said if you are in charge of your own destiny i.e. no legacy databases with weird interface rules - you really have no excuse to be rolling your own ORM you're just adding an unnecessary cost to your system in the mid- to long-term.
