I work in a large financial services company in the UK, and recently I've been prototyping various transparent persistence products, in order to submit a recommendation for our standard persistence mechanism. Out of the products that I looked at, I was able to get Hibernate and one other JDO product to perform as required. My feeling is that Hibernate is the more mature and better product, but I'm looking for help on how to present arguments that my colleagues can accept.

Criticisms that I am trying to counter include:

• Not JDO compliant. It is perceived that this would simplify migration to a competing JDO product, should the need arise.
• No support contract available (yet). Although I'm quite happy to use the forums to ask for help, some of my colleagues worry that we can't wave a support contract at someone to force them to fix bugs.
• No training available (yet). Are there any consultancies in the UK that provide training?
• Upgrades will not be backwards compatible. If Hibernate does become JDO compliant in the future, we will have to modify our codebase to upgrade.
• There are no other large enterprises currently using Hibernate (I see that AT&T and PriceWaterhouseCoopers are listed on the "Who Uses Hibernate?" page, are there any others?)

If anyone can help me with counterarguments to these points it would be much appreciated.

Cheers,
Joe

Email ben@jboss.org and have a chat if you like. We should be able to sell you something.




Well, we have plenty of training in the works at this stage. Again, email Ben and we might be able to send someone out to you.




This is simply not true. If/when we provide a JDO-compliant API, we will continue to support and develop our own APIs, since the goal of the project is: "build the best ORM solution for Java", not "build the best JDO implementation for Java". Our own APIs are much more powerful than JDO APIs, and probably always will be. JDO compatibility will be for people who have the kind of more simple business problems for which JDO is sufficient.




This is complete rubbish. Your jaw would drop if you saw the email addresses of some people who email me privately. But a continual frustration for us is getting these people to talk about Hibernate in public.


Good Luck!

Gavin :-)

Perhaps you should list "not Hibernate compliant" on your JDO evaluation, since JDO to Hibernate is the much more common upgrade path at this time.


;-)

That's a useful factoid. Do you have a feel of the number of users of the various products? A colleague has the opinion JDO = Standard = Good, while Hibernate = Proprietary = Bad. His argument is that since JDO is a JCP standard, the entire ORM industry will flock to it, leaving proprietary solutions in a dead end.

Joe

Well, standardization vs. innovation is, of course, an interesting theoretical discussion.

I'll just point out that the most mature ORM implementations (TopLink, Cocobase) have so far snubbed JDO - though it looks like TopLink will eventually provide an implementation, given the proposed changes in JDO2. The current JDO vendors are tiny companies and all have tiny userbases compared to Hibernate or TopLink. Its going to be interesting to see if any of them will be able to compete long term with Hibernate; it seems doubtful, since the technology they are charging money for is certainly not better than this free technology.

Like I said, if our goal is to build the "best ORM solution", a generic "object persistence" standard is simply going to be too limiting. We are doing what we can in the JDO expert group to improve JDO's most glaring problems but, in the end, we are simply not going to be able to get everything we need into the standard. So we just can't take the risk of betting everything on JDO.

Sometimes, standards are fantastic. eg. JMS, JNDI, TCP/IP, servlets. But object persistence is a VERY difficult area. All previous attempts at a standard have been abject failures.

In my opinion, being open source is a MUCH more important than being "standard". Obviously, commercial vendors won't agree!

I have tested a few JDO implementation, but looks like there is no way to implement any realistic application without "not standard" extentions. I am trieng to "sell" O/R mapping tools for my company too, but I do not have this problem (standartisation), the main problem is to drop "common practices" and to start "experiment" on "mission critical" projects. It is very common in financial services to use JDK 1.2, Stored Procedures or something like "Table Oriented Programming".

My company is looking for an java O/R framework and I haven't tried out Hibernate yet but from I have read it seems impressive maybe the best O/R tool currently. And I think it is promising that Gavin joined the JDO Expert group though from his postings it doesn't appear Hibernate will support JDO anytime soon. Is that correct?

If so that is disappointing because while Gavin thinks "being open source is a MUCH more important than being standard" my view is it is more important to follow an industry accepted standard and even better if there is a great implementation that is open source. If you believe the standard is good and will take hold then you have to believe there will be great implementations (open source and commercial) in the present or near future. I find it difficult to believe a proprietary solution like Hibernate will have much of a marketshare in 2 years time. Maybe I will be wrong but I think if you work for a large company with large codebase it is too risky of proposition to push a proprietary O/R solution at this time.

I think you might really want to re-investigate what defines a "industry accepted standard". Name any _major_ O/R vendors supporting JDO. A standard should grow from industry best-practices, not try to influence industries practices for the sake of some made up standard.

Good standards are invaluable; stadards for the sake of having a standard is silly.

About 4 years ago, I thought like you, and was a strong believer in "standards". Then I had the opportunity to actually work with some. I think its quite fair to say that the cost to the IT industry of terrible standards like EJB has been enormous. We are talking about billions of dollars of lost productivity here.

As Christian often points out, the real danger here is that a bad standard will be adopted, and kill innovation in ORM, which is certainly still a "developing" technology, even after 15 years or so.

Currently, Hibernate is the de facto standard for persistence in Java; it got that way by being free and open source and technically superior. If a better solution comes along, we will need to change to compete, or we will die. This keeps the pressure on us to keep innovating, which is a Good Thing.

Commercial vendors love "standards", because they allow the vendor to deliver a very limited product, and be guaranteed a market. It gives the vendors an "excuse" for the limitations in their products. It gives them an excuse to stop innovating.

Now, I am doing what I can to help improve the JDO spec, and I am confident that JDO2 will be better, in the sense that it will be at least useable for nontrivial applications. Lets be quite clear on one thing though: Hibernate 2.x is certainly a more powerful ORM solution than the current JDO implementations. JDO2 copies a number of features from Hibernate and this is certainly a good thing. However, by the time the JDO2 spec is approved (there is not even a JSR yet), it will likely be a long way behind Hibernate 2.4 or whatever we have at that stage.

To be honest, I am just a developer. I care mainly about technical superiority, and solving our user's real-life problems. I really don't care much for the "check box" approach of hands-off IT architects. "JDO compliance" sounds to me like a straightjacket that prevents me from providing the nicest APIs I possibly can. Why is Hibernate successful? Because we make software that our actual users (ie. developers) like. I promise to continue with this approach Anything else would be to betray our userbase.

Now, this does not prevent us from providing a JDO compatibility layer, just as we are providing a CMP compatibilty for JBoss, and already provide an ODMG compatibility layer. But I am sure you will excuse me if I don't make this my #1 priority for the next two months!

If I would have decided to build a JDO implementation 2 years ago then:

(1) Hibernate would suck
(2) JDO would not be making the improvements that are currently in the works
(3) The Java community would be poorer

Let me turn this around: would you not use Ant or Struts or log4j because they are not JCP-approved standards? What does a standard give you that an open source solution does not? Why does everyone use log4j instead of the "standard" JDK logging?

Hibernate is the standard; we just don't have a checkmark from the JCP.

peace

Gavin

Continuing my rant, I should point out that every previous attempt to "standardize" object persistence has failed: ODMG, CMP, JDO1.

It is quite likely that this is simply to -complex- a problem to be amenable to standardization.