Gavin et al.,

I've corresponded with the author of a well-written JDO implementation, who had some complementary things to say about Hibernate. The following points were made , however, is favour of "My JDO" and against Hibernate:

-------------------------------------------
"My JDO" has a much more flexible data loading engine than Hibernate. You can define load policies that completely control what data is loaded from the database when a query is issued or an object is retrieved. You can also completely and dynamically control how relationships are loaded.

Hibernate has some capability to do as well, but it is more limited. See their outer join fetching, lazy initialization for collections, and fetch joins for queries for details.

But fetch joins for queries are limited to one collection per query (huge limitation), lazy initialization isn't available for arrays, and when a class's properties are loaded, they must *all* be loaded. So you're going to be loading unneeded data and encountering the n+1 problem.
-------------------------------------------

I'd be interested in hearing your reponse to these points, with reference to the current and near term capabilities of Hibernate. Thanks.

1. Not true, see for yourself. The JDO v 1.0 query language is actually very weak, see the current chapter of "Hibernate in Action" on TSS for a good overview. Hibernate supports all the things you mention perfectly with three APIs (HQL, QBC, QBE). The limitation to one eagerly fetched collection is a "common sense" limitation (think about the amount of data and the tables joined in one operation), based on real experience. It is likely to be extended in a future version, but not many people will even notice any difference.

2. No one cares about arrays in practice. We never had a single request for a feature like that.

3. Not all class properties must be loaded, we have a pattern called "Lightweight Classes". We even have the requested functionality on Gavin's Laptop ;) but a recent discussion on the developer list has shown that it is mostly useless. It's a common marketing trick. Hibernate solves the n+1 selects problem very well (or at least, gives you a choice of options, see the TSS chapter).

Use the source and documentation to verify these claims. Ask the JDO vendor to provide the same.

We usually don't respond to any of those sales pitches, but the arguments in this case are pretty weak. If you need a strong argument "pro" Hibernate: Compare the query features and have a look at the Hibernate in Action chapter. Keep in mind that Hibernate is driven by user requests and common sense, not marketing and specification committees.

Well, actually, I would say that Hibernate is MUCH more flexible when it comes to association fetching. JDO does not expose any APIs or query languag for this, so fetching strategies must be defined in (vendor-specific) metadata - a is much less flexible approach than allowing this stuff to be specified in the query itself.

Yes, Hibernate does not implement lazy *property* fetching, but as christian says, we have concluded that this is pretty much a useless feature. It exposes you to the n+1 selects problem. Note that one of the things that makes it *really* useless is that Hibernate query language supports projection, which JDO does not.

So, i guess in a sense the answer to both questions is: yeah, perhaps My JDO supports more (vendor-specific) metadata-level feautures, but that is really only because of limitations to JDOQL. Hibernate doesn't need it because our query language is so much more sophisticated.

Personally I would rather just look at the query and be able to see "everything", rather than have to piece together stuff from the query + metadata. But your taste may be different, I guess.

P.S. re arrays:

(1) it is better to use the collections framework, anyway
(2) JDO does not have automatic dirty checking for arrays; Hibernate does
(3) no lazy loading does NOT mean n+1 selects; you can use an outer join instead!

Also, be very careful when comparing a commercial product with an open source product on the basis of what salesmen tell you.

(1) All the JDO vendors have done full competitive evaluations of Hibernate against their products, since we are the main "competitor" they see in the field (along with TopLink, I guess). We have not, since we rarely meet JDO (we are much more interested in comparisons vs TopLink) and because there are simply so many tiny little JDO vendors and we just don't have time to evaluate and stay up to date with all their feature sets!

(2) On the one hand, you have a guy selling something to you in person; on the other hand, you are judging from our website. To put us on a fair footing, you would need to be talking to us in person, which is possible only if you are interested in purchasing commercial support, or if you come to training. (We have waaaay too many users to give that kind of personal attention to everyone.) This is one of the reasons I believe in this notion of 'professional open source', since it puts us on a fair footing with our commercial competitors.

Anyway, just some thoughts, which I never wrote down before; take 'em or leave 'em.

peace :)

cool peace ||

cheers Hibernate I love you

Gavin,
"notion of 'professional open source'", you don't know how you are right saying that.
When my team was created last year, we needed an orm tool and the other teams of my company (production, technical architecture for example who never coded 1 line of java) where joking about open sources projects.
We had to "fight" against these ideas. What big company want is to be able to say "if a problem occurs in production, it is due to Oracle or JBoss not to my team".
It's completely ridiculous because 99.9% fo problems are due to developper, i know what i say, i've coded many bad codes in my life :-/.
So i think that selling training and support in addition to your forum and free docs (which are perfect) is the best way for hibernate to continue growing. By selling that, company will be more entrusting.

if a problem occurs in production and you use "X" DB, you can blame it( they stold your money). If you use PostgreSQL (it is almost the same as "X" DB for most of applications) you need to blame yourself.
Open source is a very bad thing for most of "enginiers" and I am not sure
it is possible to change. I think JDO will never die too, some not so bad implementation just need to be more expensive than "Y" O/R and it will win the market.

I would really be interested if anyone ever got anything from a software company he bought something of, because that software trashed his data or shut down his buisness for a day ... I never heard of something like that, did anyone? (really just interest, not a troll :)

I do not think somebody got money back from sofware company, but you do not need to solve any problems if you buy expensive sofware, just write a letter for support and wai a few years for bug fix, you are safe, it is not your fault.

I only want to say that when you choose struts or hibernate, you don't take a lot of risks.
If you take a "free" new database instead of Oracle, Sybase, SQL server... yes you can blame yourself if something happens in production.
I've used a relatively expensive UML suite which allows you to generate a lot of things, but this tool had thousand bugs.
And as Michael said, no way to get money back, just wait 6 months for new release: they call it "new release" no "fixes".
And during 6 months, we had to do twice or more the same job.
So as many said, be carefull with sales pitches.
I think the only real factor are the users, only users can say if a product "free or not" is powerfull and safe.
About this "UML bugging suite", i went to a meeting, this society was sponsorised by a direct concurrent..., this sponsor made a training on ORM, when the questions about "other products" happened, the guy didn't fing any technical argument against hibernate. So this "expert" (sure he was) only said "Hibernate = fashion, it will die".
So if a commercial support training can change "non user minds" ... come on :)

Excuse my english is bad, but i think it's dangerous to say that if a product is free and with no support, it is a bad product cause "somewhere" it's more risky ...
Don't forget JDK is free...

Probably if you are at a really big company, and pay really a lot to a certain business you could get some "reparations", because they want to keep you as a customer. But I really don't think that if you are a normal sized company anybody will give you anything if something goes wrong with the software you bought (especially because it is really hard to prove it was not your fault)

Yes, I never buy infrastructure code if I can decide too. I can solve all of my problems myself and I OSS helps me. Closed source is much better for lame "architects", they want to live too.

Thanks, everyone, for taking the time to respond. All things considered, I intend to use Hibernate on my next project.