The comment, Re: iBATIS vs Hibernate, offers some good advice for when to use iBATIS and when to use Hibernate. The damning sentence for Hibernate follows:
If you try to shoehorn hibernate into a relational model created by a DBA who could care less about objects and thinks in terms of tables, columns, relationships and record sets, then you will get along better with your DBA if you use iBATIS, especially if the model is complex and may entail queries with outer joins and nested subqueries.
Since when did outer joins or sub-queries become "complex"? These are exactly the drawbacks we've discovered in Hibernate, as well. You have to do handstands to get it to do an outer join; once you've got one, the object-structure returned by Hibernate is different than it was before and your processing code is useless. Which takes us to this next sentence:
iBATIS is more flexible, has a shorter learning curve, but can take more time to develop and maintain, since you have to write all your queries and if your object model changes you have to go through all your queries and make sure to make all the necessary changes to reflect the changes in your object model.
With Hibernate, you have to re-adjust how you process the query result if you change something that Hibernate considers significant (like restricting an inner join -- a big no no). Each solution has the downside of requiring maintenance when something changes. iBATIS fails outright when it tries mapping (database) fields to (object) properties that no longer exist. With Hibernate, it's possible that the code keeps running fine -- it just starts reporting 20 objects, where before there were 5 (with 15 children distributed among them).
The article, iBATIS 2.0 Released, provides more information in the comments.
Sign up for our Newsletter