TopLink vs Hibernate... revisited... again :)

Question

Would it be possible to get a Toplink versus Hibernate (or other ORM frameworks) going here?
It seems like the explosive adoption of Hibernate and the associated popularity contest in the industry has put some of us in a position where we're constantly trying to sell the-right-tool-for-the-right-job which, at least for me, seems to disqualify hibernate a lot of times, esp when scalable persistence is a requirement. It seems to be really difficult to convince folks that the popularity of hibernate doesnt mean it's by default the right option.
I've seen at least two threads on theserverside.com about hibernate versus cayenne, and despite the amount of noise in the threads, there were a few folks making some decent points. The TopLink folks were very quiet on the threads, but I know they were reading :)
So, anyone out there have any experience comparing TopLink and Hibernate? What do you all see as the shortcomings of each, esp from a technical architecture standpoint? Are GUI tools as overrated as Gavin claims? Where's annotation support for TopLink? Is TopLink overpriced? Is Hibernate's multi-tier non-integrated caching biting anyone on big projects where persistence needs to scale, or is integrated caching overrated? Is Hibernate3 really going to fix shortcomings that TopLink already addresses in current releases? What do you all think the Hibernate crew is doing right that the TopLink crew is doing wrong and vice versa? I'm not assuming any of these questions even merit answer but just interested in some objective discussion in a forum where TopLink guys might have a stronger voice.
Take care!

Answer 1

Well, I've only got a few minutes, but I could go on for hours.
I'll start by saying that I've been doing ORM for longer than many people knew that you could. I had been a previous TOPLink user but went for about two years without having to do any ORM.
Then, last year I started a new project for a client who insisted we use SqlServer and was hesitant to pay for any software unless it was absolutely necessary. (This is common these days, as the fact that there is so much free software out there encourages folks to try out the free stuff before paying for something that may or may not be better). Comparing the feature list of Hibernate to TOPLink and doing a little checking seemed to indicate that going with Hibernate would be a perfectly reasonable thing to do.
I will state, uncategorically, that this was the worst technical decision I have ever made in my life... twenty-plus years of Software Application Developing, most of it with object-oriented languages (Smalltalk and Java).
NOTE: I must couch that statement with the caveat that part of this was due to my naivete about the architectural assumptions I made about Hibernate before including it in my application. If I would have merely learned about Hibernate's architectural assumptions (though this was not easy due to their poor documentation) and allowed these assumptions to drive my development, it would not have been nearly as painful, just yucky. Also, if my objects were much simpler/flatter and I didn't need caching to speed things up, Hibernate could have worked just fine out of the box. Problem is, I had a complex system, needed caching, and Hibernate gave me nightmares as I tried to navigate through it.
As a test-first developer, I don't care about the GUI tools, as I'm happy to write tests to verify I can store and retrieve objects, then write the mappings and find out if it passes. What I would like is the ability to allow two threads to read the same object and not have to bring two copies of the object into memory or read the database twice. Call me crazy, but it just seems like object identity is a useful thing... perhaps my twenty years of developing object-oriented software has skewed my reasoning and I need to think like folks who haven't been programming as long.
Hibernate's poor documentation did make it clear that it did not want me to think this way, but it also suggested that, if I wanted to think this way, it could cache objects for me so it wouldn't hit the database twice. And, I'm sure it could have cached objects in some form, but not the form I wanted. Though I thought I followed the instructions on how to set up my cache, I found that reading the same object twice didn't always get the same (as in "==") object back.
To try to figure out why not (or why other things that an experienced object-oriented software developer couldn't figure out by reading the documentation), I had to dive into the code. This felt like diving into a water source in hopes of finding some gems, but discovering that I was swimming in a sewer full of, well, stuff that you'd find in a sewer.
Although Hibernate advertises itself as a framework, it is much more of a blackbox framework than a whitebox. Most of the methods and many of the classes are private or protected final. There are very few places to extend what's there. And there are virtually none that allow you to override their architectural assumptions.
The biggest architectural assumption I found to be problematic was that application developers can't be trusted to know which objects they intended to read and which they intended to write. Therefore, Hibernate "protects" you from having two sessions refer to (that's right, refer to, not modify) a collection of objects.
In the end, we ended up having to open up the source code and make some modifications in order to make our application run with reasonable performance. We had a lot of fairly deep objects (objects that contained objects that contained objects...) and the idea of not caching the ones that were not being modified across sessions just didn't cut it for us.
Additionally, we've spent the last few months supporting the app that we finally got into production, and greater than 75% of our bug fixing time has been due to the fact that Hibernate actually reads in objects from several places and it is difficult to tap into THE place an object is read in... because there isn't one. It goes through all sorts of intermediate states and we found out that having one process that is reading objects while another is trying to write the same object can cause some unfortunate side effects, even if you put synchronization locks in the obvious places.
We ended up with many person months of effort and a lot of special classes getting Hibernate to do what we wanted it to do, and had to open the source code (which will make it hard to ever upgrade to the next version).
Just recently we started a new project (where Oracle was the corporate standard DB) and decided we'd try to use TOPLink. Having not used it for several years, I had hoped it was going to be much cleaner than Hibernate to hook into our persistence layer. It was a piece of cake. In a few days we were doing what took us months to do with Hibernate, and we didn't have to perform any unnatural acts to get there.
I would recommend Hibernate to anyone who didn't know how to build a reasonably factored object-oriented system and didn't mind forcing their system architecture to fit Hibernate's architectural assumptions. But, if you think you might have reason to define your own architecture or modify Hibernate's default behavior, TOPLink is well worth the licensing fees. Not to mention the cost of your sanity.
Is Hibernate really free? Only if you don't value your time. I also found that you can buy outrageously priced support from JBoss to make up for their poor documentation on their poorly architected ORM blackbox framework. The documentation for TOPLink is far superior, and the simplicity of doing simple customizations and tweaks is like night and day.