SQL Zone is brought to you in partnership with:

Rick has posted 25 posts at DZone. You can read more from them at their website. View Full User Profile

Is Hibernate the best choice?

02.19.2008
| 136787 views |
  • submit to reddit

Is Hibernate the best choice? Or is the technical marketing of other ORM vendors lacking?

Recently Jonathan Lehr posed a question on his blog: "Is Hibernate the best choice?", and this lead me to ask the same question.

Although, I tend to use Hibernate as my first choice, it would be nice to see some head to head comparisons of Hibernate vs. TopLink (pros and cons), Hibernate vs. OpenJPA, Hibernate vs. Cayenne, etc. Searching around finds that many of the comparison are pretty old and not very detailed or compelling.

Having used other ORM frameworks, I found that when something goes wrong with Hibernate, you can usually google and find an answer, and there are many books on Hibernate. In my experience, the other frameworks seemed to be a less well-worn path and it is harder to find answers to even common problems. This is not to say that Hibernate is better, but that it is a lot more popular. In the end, I use Hibernate because my clients use it, if my clients switched to TopLink or OpenJPA, then I would use them as well.

So this begs the question, if Hibernate works for you, you just might have something else to do, like implementing a client solution that makes your client money, than to try several other ORM frameworks. How much time should someone spend learning a new ORM framework (new to them anyway)?

Don't get this wrong, trying out new ORM frameworks is fine. If there is a large IT/developer organization, and you have a certain selection criteria like integrating with legacy databases, conformance to JPA specification, ability to hire new developers, easy of use, etc. then by all means having someone create a few prototypes and/or proofs of concepts and try out a few ORM frameworks is great. There is often good ROI in this type of testing. Perhaps share your findings with the rest of us.

However, it seems if you are a vendor of a JPA solution, you could start by pointing out how your product differs from Hibernate. Like it or not, Hibernate dominates the mind-share of developers. If you can't prove your ORM frameworks has compelling reasons for switching, why should developers spend their time evaluating your product?

Now let me boil things down to brass tacks, it seems vendors of the ORMs should write white-papers, articles, blogs, and such to highlight the advantages of their ORM framework versus Hibernate. Logic dictates that if you have a product and there is a competing product that dominates the market that you might want to highlight what differentiates your product from the dominate one.

As a test, let's go to different vendor sites and see if they have comparisons of their ORM framework vs. the 800 pound gorilla, Hibernate.

So first let's go to Oracle TopLink website, you would expect since Hibernate has such a huge adoption rate in the industry that Oracle would want to point out why TopLink is better like a nice white-paper perhaps featured prominently on their TopLink site (see graph).

TopLink versus Hibernate

After hunting around a bit this entry appeared in the TopLink Essentials FAQ, Why should TopLink Essentials be used instead of JBoss(TM) Hibernate?

The two main points that seemed intriguing were as follows:

"Customers with any degree of complexity in the domain model or relational schemas, most notably where changing the schema is not an option, will benefit from the flexibility and proven nature of TopLink."

NOTE: At times mapping Hibernate to legacy systems can be challenging. How is TopLink better at this? Are there articles or white-papers, etc. that attempt to prove that TopLink is better at legacy integration? (I find that many developers are not aware of all of the features that Hibernate provides for legacy mapping.)


"As the reference implementation of JPA TopLink offers the first certified implementation of this new standard. as well as providing some useful value-add functionality. Going forward this open source project will continue to innovate based on contributions from Oracle, Sun, and others."

NOTE: This is compelling to me since I now use the JPA interface to Hibernate whenever I can.

Now I did not find the arguments in the FAQ particularly compelling or at all detailed. Sadly, you can find more compelling arguments in some of the TopLink public forums and random blogs. However, none so compelling that I feel the sudden need to switch.

Now on to the BEA site to look at dear KODO. I have always heard good things about KODO. Sadly, I found the BEA KODO site to be very out of date. It mentions a 2005 award for KODO as the lead news item. It also mentions that OpenJPA is in incubation, it has been out for a while. Even the FAQ, which did mention Hibernate, merely mentions that Hibernate is not EJB3 (seems it should say Hibernate is not JPA). This site really seems out of date and like the TopLink site mosty ignores the elephant in the room (see graph).

KODO vs. Hibernate

Well, let's look at the Apache OpenJPA site, as KODO's DNA may live at Apache long after Oracle decides on a single JPA solutions and likely leaves KODO to rot on the vine. Searching through the main site, FAQ, OpenJPA documentation, etc., I find no mention of Hibernate. Now this is an open source project so one would likely expect to see no marketing angle per se. But, you might expect that a project recognize that many would not be able to use this project without first justifying their pick against picking Hibernate (OpenJPA barely appears at all on job graphs). How many IT/development managers will feel comfortable with this choice without some explanation?

Now on to the next ORM framework site, Cayenne. No mention of Hibernate vs. Cayenne (but I know I have read articles on this). Seems like there might be some compelling ease-of-use arguments for Cayenne vs. Hibernate but they choose not to compare them. (Cayenne barely appears at all on job graphs)

Now back to Jonathan Lehr blog, Jonathan states that he feels TopLink and Cayenne are better choices than Hibernate and cites his reasons for these choices. There is a long discussion on the pros and cons of each in the comment section. I'd love to see more discussion, and I'd love to see some viable alternatives to Hibernate, but feel that no vendor or open source project does a real good job of pointing out the differences and possible limitations of Hibernate. If the vendors and project owners choose not to make their case, it makes it very difficult for the rank and file developers to make their case.

Perhaps one reason Hibernate is so dominate is because competing projects are so bad at technical marketing. Not one project I looked at mentions Hibernate on their front page. I could not find a decent comparison of features (to Hibernate's) on any of the ORM sites.

Has anyone done a comparison of Hibernate and OpenJPA, TopLink Essentials, Cayenne that compares ease-of-use, caching, tool support, legacy integration, etc.? Perhaps such an internal report was used to decide which ORM tool to pick. If so, what were the results?

If you use TopLink, OpenJPA, Cayenne instead of Hibernate, why?

Were you hoping that JPA would level the playing field and there would be more competition?



About the author

Rick Hightower is CTO of Mammatus and is an expert on Java and Cloud Computing. Rick is invovled in Java CDI advocacy and Java EE. CDI Implementations - Resin Candi - Seam Weld - Apache OpenWebBeans

Published at DZone with permission of its author, Rick Hightower.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Sebastian Jancke replied on Tue, 2008/02/19 - 1:14pm

Personally, I'm using Hibernate and NHibernate. I would also be interested in Feedback on usage of other ORMs.

Currently, I'm doing lots of .NET work, and it's really "funny" to see, how people are still complaining and debating about the whole ORM-Idea (there is a very interesting open table discussion on dotnetrocks podcast). Further, Microsoft is going right in the ORM market, reinventing the wheel and delivering Entity Framework on top of their .NET 3.0 LINQ - while we have already a good NHibernate and OpenAccess and iBatis and ... (couple of other ORM's in the .NET world).

 I think it's really refreshing to see (Java) people discuss about alternatives and not debating on ORM vs DataSets (aka direct coupling of your UI to DB with Microsoft Automation).

Just my cents...

 

David Lee replied on Tue, 2008/02/19 - 1:52pm

Not if you know SQL.   Hibernate has is benefits once you've truly mastered it.  Until then, you will be less productive and fustrated learning HQL and the the other ways of hibernate.  Personally, it's just not my cup of tea.  I prefer iBatis.  Yes you will write SQL, but if something is not working right, the problem is much easier to fix.  I worked on a few projects w/hibernate and there is nothing more fustrating than having to do it the hibernate way, when a simple query via iBatis or straight JDBC would have solved the problem in minutes.  I'm talking about table relationships involving composite keys to name one example. 

It simply takes experience and perspective to know when hibernate is the best choice.  Sometimes it can be, but not always.

Matthew Adams replied on Tue, 2008/02/19 - 2:32pm

Note:  I am on both expert groups, JPA & JDO.

You skipped another open source implementation not only of JPA, but also JDO, which is JPOX (http://www.jpox.org).  I have heard good things about it, and it is also the RI for JDO 2.0.  I think they have a decent feature matrix on their site, but I don't have time at the moment to have a look (doing real work ;) ).

FWIW, without starting a holy war, I agree that there should be comparative analases of ORMs as well as APIs (JPA v. JDO).

Andrew McVeigh replied on Tue, 2008/02/19 - 2:36pm

i used toplink extensively from '99 through to about 2004. i even brought it into a few large projects, including a huge project where we did a face-off versus hibernate and JDO (I wrote/debugged the winning toplink PoC). I haven't touched it since then, so some/all of the info may be out of date now -- for all i know they have fixed up a lot of these problems.

toplink was fine, and had advanced mapping options (nice GUI), but it fell down very badly in 2 areas:

1. cache management

It's very important to treat read-only (or slow moving) objects and transactional objects differently for caching. Toplink was poor in this regard, accessing all objects through the same session cache. We ended up using a separate session for each transaction, and i've seen others write horrendous code to selectively rip the transactional stuff out of the cache. Yuck. Hibernate was like a breath of fresh air in this regard.  what also annoyed me about the toplink consultancy we used was their refusal to acknowledge that it might need a different approach for the different types of objects.  The code that Oracle sent us for dealing with this in my last project doesn't bear thinking about...

2. transparency

At my time of using it, you had to embed fairly horrible objects for handling lazy access. e.g. class Car { private SteeringWheel w; } would become class Car { private ToplinkHolder w; } or something like that. Hibernate handles this under the covers. There were other things also. Very much against the modern pojo approach.

There were other things, such as poor documentation on the query language, poor support for resolving objects in memory (conforming to cache), rude consultants with ponytails, etc etc. Based on what i've experienced, i would never go down the toplink route again...

Andrew

p.s. I've also been screwed three times when this product changed vendors and licensing terms changed. from toplink to webgain we ended up paying per deployment rather than the previous per-developer. when webgain were in the throes of despair, i think they spun it out into another company and we ended up paying a big lump sum to guarantee prices. then when it went to oracle we paid again... do yourself a favour and stick with something that can be owned by the community, like hibernate.

Andrew McVeigh replied on Tue, 2008/02/19 - 2:42pm in response to: Matthew Adams

FWIW, without starting a holy war, I agree that there should be comparative analases of ORMs as well as APIs (JPA v. JDO)

I've worked extensively with ORMs (mainly toplink, >5 yrs fulltime) and also quite a lot with JDO.  (I see JPA as a sort of cut down JDO, pushed into the relational-only space).   I've also spent a whole lot of time with object databases (Versant, ObjectDB etc).

 For my money, JDO is streets ahead of any API out there.  The clean API, couple with the strong lifecycle definition for objects has made it a pleasure to use.  I'm using it at the moment (with an object database) and I love it.  My impression is that much of the criticism has been around the bytecode enhancement (goes away with JDO2, not too bad even with JDO1) and political positioning.

I've had a look at JPOX and I think it is great.

 Andrew

christiaan_se replied on Tue, 2008/02/19 - 3:00pm

I use Kodo JDO and I am very pleased with it. The JDO spec really enables transparent persistency in my opinion. For our application it simply makes development more efficient and it is a big plus to have your data persisted in a very consistent (automated) manner. Having a vendor independent ORM spec was actually one of the reasons to choose the Java platform instead of .Net (Microsoft was working on a ORM layer which never left the research stage at the time). The reason why we didn’t choose for hibernate is that it lacked some features we needed (I believe it was multithreading and non-transactional reads at that time, but that is already a couple of years ago so I can imagine that has changed).

 

Before JPA, there were quite some implementations available for JDO. One of the major issues on which they could compete was performance, so there was actually an official performance benchmark set up (http://www.torpedo-group.org/). I think JPOX, the opensource implementation of JDO, has still some benchmarks on it’s site in comparison with hibernate. Anyway, you will still probably find a lot of discussions on the pros and cons between JDO and Hibernate. Anyway, the advantage of the specification is that you can easily can compare implementation on feature set, since some of them are optional.

 

Unfortunately, there were two things which slowed down (or stopped?)  the promising process of JDO:

1)      Some large companies took over the small innovative JDO vendors and didn’t deliver the support that they had before or simply stopped supporting it;

2)      The JPA spec came around which is essentially a clone/subset of JDO. This put back the development of a good persistence framework and implementations in the java community in my opinion. I really think Sun should have avoided this situation. It is a good thing you have competing implementations, but having competing specifications is a waste of time.

 

Kind regards,

Christiaan

Roman Pichlik replied on Tue, 2008/02/19 - 3:30pm in response to: David Lee

Yes you will write SQL, but if something is not working right, the problem is much easier to fix. I worked on a few projects w/hibernate and there is nothing more fustrating than having to do it the hibernate way, when a simple query via iBatis or straight JDBC would have solved the problem in minutes.

There has been N+1 problem with iBatis with no simply solution opposite to Hibernate since you may use different fetching strategies e.g. batch fetching. If you are not satisfied with some HQL queries or their performance then you may still switch to plain SQL and let Hibernate to map a query result into your domain objects according to their mapping metadata. iBatis is good solution for simply use cases e.g. mapping a query result to object graph, but Hibernate is far away behind it.

I appreciate following features of Hibernate:

  • support for mapping legacy RDBMS (user types, mapping a class more than once)
  • API is designed in order to be extended (session listeners, object serialization/deserialization aka tuplizier, property access strategy)
  • lazy fetching per single property (involves byte code instrumentation), useful for a BLOB property
  • transactional and second level cache
  • Criteria API

Matthew Adams replied on Tue, 2008/02/19 - 3:40pm in response to: christiaan_se

RE:  1) One of the small innovative companies still working on JDO is Xcalia (http://www.xcalia.com).  Truly the most innovative use of JDO I have ever seen (try mapping your objects to databases and services, instead of just databases), but it is commercial.  AFAIK, BEA is still writing and supporting Kodo JDO.

christiaan_se replied on Tue, 2008/02/19 - 4:27pm

BEA is definitely writing and supporting Kodo and I am glad they do that. The support and development is not at the same level as it was with Solarmetric, which is reflected by the out-of-date state of the website as Rick Hightower mentions.

Ron Pressler replied on Tue, 2008/02/19 - 6:13pm

Though we've never tried Hibernate, we've been using OpenJPA for quite some time now for some very complicated stuff, and are very pleased.

We chose OpenJPA over Hibernate because its integration with JPA  seemed more natural (we like standards), and its additional features use annotations and an extended EntityManager in a very similar fashion to the JPA standard.

We found OpenJPA to be extremely versatile (it is highly configurable, with options covering almost anything we could think of and then some, and it can be extended with user defined classes without too much difficulty). Its additinal functionality allowed us to work with JPA offline - i.e. we never clear the EntityManager, but keep it continually in-sync with the database, even though other applications modify the database directly. Its documentation is quite satisfactory (it has a very good manual), and so far we didn't require any forum assitance.

With regard to performance - after adding a PreparedStatement cache to our DB connection (this gives a huge performance boost to OpenJPA), we found it to be more than twice as fast as Toplink. 

Michael Parmeley replied on Tue, 2008/02/19 - 6:20pm

I have only ever used Hibernate and I stopped using it as I was never able to get Hibernate to produce well performing SQL. The inability of Hibernate to populate multiple Collections with sub-selects in a single object is a show stopper for me.

I have an object that has 7 Collections that need to be populated (through linking tables). I can populate this object with 8 SQL statements. The best I could get Hibernate to do was to use the "batch" attribute which at least got it away from doing n + 1 but never could get it to do it in the 8 statements I could do it in with my hand-coded SQL. Even with the "batch" attribute the number of queries it need to do was still not constant, whereas no matter how many rows the collections had I can always populate it with 8 queries.

I think ORM is a solution looking for a problem. The coding time you save from using a ORM you lose in figuring out how to map all of your entity relationships and creating the actual mapping files (I could never get automated mapping generators to work perfectly, would always have to edit the files after it did its generation). I also still found myself writing a lot of boilerplate DAO's. I am really not sure there was a time savings.

I am open to the idea that it is my own ignorance of the mapping process causing the less than optimal SQL generation; however, I spent who knows how many hours reading books, documentation, forum posts, etc figuring out the best way to use Hibernate and could never solve my performance issues. That goes back to my point that I don't believe ORM tools save you time.

Don't even get me started about the elitist attitude you find in the Hibernate forums. (I am not bitter I swear!)

I would be really interested to know how the other ORM's do with optimal SQL generation, especially with collection mapping.

JeffS replied on Tue, 2008/02/19 - 7:55pm

"I think ORM is a solution looking for a problem."

 I agree.  It stems from over obsession for all things OOP, or "domain driven design".  The relational model, which works spectacularly by the way, isn't good enough for people really interested in pure OOP.  Thus, they feel the need to force a sqaure block in a circle slot, and come up with ORM.

 Don't get me wrong, OOP is great, for certain things - like non-specific, generic, reusable in many situations, code.  But the more specific a problem domain becomes, the harder it becomes to contort the OOP model into that problem domain.

 And ORM is a big contortion for matching OOP to the relational model.  It has it's advantages for basic sql stuff, but when you get into very specific, very complex sql database stuff (which represents a lot of real world scenarios), ORM becomes a mess. 

 Thus, I like plain old JDBC, or something less ORM-ish, like Spring JDBC (basically, wrapper methods on top of JDBC, making it simpler and requiring less boiler plate), or iBatis, which lives more naturally with regular SQL and stored procedures.

Tom Pridham replied on Tue, 2008/02/19 - 10:42pm

I prefer iBATIS.

 

The job market is full of Hibernate requirements when looking for Java Enterprise Engineers. Hibernate is a very good product. Managers who decide to bring Hibernate into their shop / product must remember a few key items. First is the learning curve that all members of the dev team must overcome (that will cost $$$ in lost productivity). Second, if you must replace or fill new positions, you must find people with Hibernate experience of you'll bite the financial bullet on the learning curve again.

 

I think the best path to ORM is to use interfaces and IoC (via Spring) to separate the db activity. Bring in iBATIS first, then slowly migrate to Hibernate. Ditch all Entity EJBs and just use MDB and Session EJBs when needed.

 

Just my 2 cents.....not intended to start a flame war or spread FUD.....just my first hand experience from the trenches.

 

Regards,

Tom

Clinton Begin replied on Tue, 2008/02/19 - 11:44pm

>> There has been N+1 problem with iBatis

I'd love to hear more about what N+1 select problem you are experiencing. iBATIS has been able to map complex joins of almost any depth or breadth for well over 4 years now...

Post a message to our mailing list with the problem. Otherwise, FWIW, I can only say that this statement is inaccurate.

Cheers,

Clinton

Yuen Chi Lian replied on Wed, 2008/02/20 - 12:57am

Good blog over there. Thanks for bringing this question up because at times, people ask me the same question.

Rick Hightower replied on Wed, 2008/02/20 - 1:37am

Hibernate supports customizing queries with plain old SQL. The support is great.

BTW Thanks for the comments, however, it would be nice to hear from some of the JPOX, OpenJPA, Cayenne guys. I'd love to hear what they think is so compelling about their ORM frameworks that would make someone who knows Hibernate want to switch.

I consider my Hibernate knowledge paid for at a dear price. I spent a lot of time reading online docs, forums, books, experimenting, prototyping and writing applications. I spent quite a bit of time tunning Hibernate apps to run faster, to use 2nd level cache, to use custom SQL, etc.  I am not saying I would never switch or that Hibernate is the perfect tool for every application, but I've had a lot of success with it and the knowledge and experience is already bought and paid for.

Let's say OpenJPA was 20% better at legacy integration, and 10% better at performance (I don't know if it is or is not)... I am not sure this would be enough reason to swtich.

When I first started learning about JPA, I was not very happy with it but after working with it, reading the spec., etc. I find JPA refines the concepts in Hibernate and simplifies them... makes them more coherent. It took me a while to warm up to JPA but not that I have....

Is Hibernate the best JPA implementation?

 

rick hightowercto of arcMindbloglinkedin

Gene Wu replied on Wed, 2008/02/20 - 2:44am

"Is Hibernate the best JPA implementation?"  I doubted.

I have several years experience with Hibernate. To resolve some issue of project, I had read a lot of src code. When I start my first EJB3 project, I prefer Hibernate as well. But, the thing is, EntityManager of Hibernate doesn't satisify me. As an implementation of JPA, I found it doens't work with some of the JPQL. Then I turned to OpenJPA, even the version is 0.9.7, it rocks! You know the 1st impression is very important.

And so far, I knew the BEA, IBM, Apache will use OpenJPA as default implemenation, it doens't mean you can not use Hibernate, but default one have commercial support with J2EE server. Meanwhile, it will be more easy to use default one.

From developer's perspective, it will be a very good investment for the coming years. Maybe more company will add JPA and EJB3 into job descrption sooner or later. What ever OpenJPA or EM of Hibernate, JPA will be the winner.

But it's up to you!

Roman Pichlik replied on Wed, 2008/02/20 - 4:45am in response to: Clinton Begin

I'd love to hear more about what N+1 select problem you are experiencing. iBATIS has been able to map complex joins of almost any depth or breadth for well over 4 years now... Your documentation is not clear about it ;-). Correct me if i`m wrong, but there is only lazy loading and join opposite to Hibernate. Please take a look to Hibernate fetching strategies (http://www.hibernate.org/hib_docs/reference/en/html/performance.html). In addition you may dynamically change fetching strategy in Hibernate. I don`t see similar functionality in iBatis.

Sebastian Jancke replied on Wed, 2008/02/20 - 5:50am in response to: David Lee

Yes you will write SQL, but if something is not working right, the problem is much easier to fix. I worked on a few projects w/hibernate and there is nothing more fustrating than having to do it the hibernate way, when a simple query via iBatis or straight JDBC would have solved the problem in minutes.

Well, first of all: You could have done that with Hibernate also (simply fire some direct SQL statements). Second, I don't really want to write SQL and get objects. Since objects are for complex logic a very nice way to handle things, I just want to use objects to query. Hibernates Criteria API is a simple and good-readable internal DSL for just that issue. Further, what I really miss in (most) other ORMs is the widespread support for different Caching strategies and packages.

What I really like about Hibernate (and iBatis), is the really closely ported API from Java to .NET. As my current job requires working for Java and .NET customers, this is an important thing. The possibility to reuse knowledge is a real killer criteria.

Another criteria for me is Spring (.Java and .Net) integration with ORMs. That is not such a huge problem in Java, as Spring gives you integration for all major players. Currently, on the .NET side there is only NHibernate and iBatis, while one can argue, if there are currently more major players in the .NET world.

For beginners, Hibernate is a beast. I agree on that. But face it, ORM is a difficult task and there is no silver bullet. Some situations don't fit Hibernate. Others require modifications to it (Lazy Loading outside of Request-Response environments aka Desktop UIs anyone?). My personal experience here is, that simply skipping LazyLoad for UI binding and telling Hibernate exactly what to load is a good option.

 

Christian Sell replied on Wed, 2008/02/20 - 5:47am

I am using TopLink in my current project, and have had to delve deep into its inner workings due to extensive app refactoring and toplink version migration. What I have seen in the TopLink source code has put me off very much. Large parts of the code obviously stem from the time when TopLink was ported from its original Smalltalk code base over to Java 1.0, and the people doing it had only learned Java a short while ago.

When doing the version migration (9.0->10.0), our application started throwing ClassCastExceptions from inside TopLink. We were able to analyze the problem only by using a decompiler (source code not available). The resulting code showed a cast from an interface typed method argument to an implementation class. Yuck.

We are also enountering massive memory leaks after the migration, which are acknowledged by oracle, but a patch is not yet available.

I think in most situations an ORM is a good choice, although not a free lunch. In choosing an ORM, I would always go for real Open Source, in particular Hibernate/JPA.

Christian

Andrew McVeigh replied on Wed, 2008/02/20 - 6:06am in response to: Christian Sell

What I have seen in the TopLink source code has put me off very much.

 We did the same thing -- we decompiled to fix a problem.  Then under license, we eventually got the code.  I had exactly the same feelings as yourself.

Andrew 

 

Jörg Buchberger replied on Wed, 2008/02/20 - 7:17am

More food for thought...

 

image #1 - absolute number of related job postings:

 

image #2 - relative growth of related job postings:

 

 

--Jörg

Jörg Buchberger replied on Wed, 2008/02/20 - 10:13am

We've been using iBATIS for almost five years in production now.

There never were any significant problems.

Whereever necessary, it was easy to tailor it to our needs. 

Compared to many other libraries and tools in this field, it is more lightweight, relatively easy to learn and comes with fewer third-party dependencies.

To sum up, we're satisfied with the software itself and the support received from its developers - both before and after it became an Apache project. The project in general seems of stable health. 

;-)  and no, I don't get paid by Clinton or anyone else affiliated with iBATIS

 

Cheers,

Joerg

 

Adam Davis replied on Wed, 2008/02/20 - 10:35am

I have another angle for you. Why should I learn Hibernate? We're mostly using Torque at my work. I can not recommend Torque, but I know it well enough to use it at an intermediate level. I have used iBatis on one medium-sized project and I would recommend it. The best thing about iBatis (IMO) is its easy to learn. I have also maintained a small Hibernate project and it seems easy to do simple things, but not so easy to do more complex things.

Rick Hightower wrote:

I consider my Hibernate knowledge paid for at a dear price. I spent a lot of time reading online docs, forums, books, experimenting, prototyping and writing applications. I spent quite a bit of time tunning Hibernate apps to run faster, to use 2nd level cache, to use custom SQL, etc.

So, as one of the uninitiated, Is it worth my time and effort to learn Hibernate?

Andy Jefferson replied on Wed, 2008/02/20 - 12:50pm

> it would be nice to hear from some of the JPOX, OpenJPA, Cayenne guys. I'd love to hear what they think is so compelling about their ORM frameworks that would make someone who knows Hibernate want to switch.

Well JPOX has existed for 4.5 yrs; longer than some of the options you actually "considered" (e.g OpenJPA). JPOX publishes the results of benchmarks on its site, regardless of whether they show JPOX to be better or worse than any competing product. Have you got such a promise on any other ORM ? JPOX docs states that if it is found to be deficient in any particular area relative to competing products then we will work to remedy the issue. Have you got such a promise from your "selected" ORMs? Indeed, do they take benchmarks seriously, or just dismiss them ? See here http://www.jpox.org/servlet/wiki/display/ENG/Polepos

JPOX is the most standards-compliant open source ORM around. It is fully compliant with JDO1.0, JDO2.0, JDO2.1, JPA1. The last two of these were completed in the last month. It also implements support for the OGC Simple Feature Specification. So if standards compliance is high on your list of priorities then JPOX should be considered!

JPOX has an architecture, based around OSGi bundles, that permits the swapping in/out of virtually all components. Do you have such configurability on any other ORM ?

JPOX is Apache 2 licensed. This matters to some groups.

JPA1 is a weak specification, as has been said before. http://www.jpox.org/docs/orm_relationships.html and so, in its current form, will never level any playing field. We, JPOX, generated comparatives of JDO and JPA They are present on the JPOX site, and the Apache JDO site.

JPOX supports persistence to multiple types of datastores ... RDBMS and db4o currently.

JPOX docs are up to date. In fact built every night! They reflect accurately the JDO/JPA APIs and JPOX's support for both.

So in summary, all of the information as to why JPOX should be used is on our website. We don't spend our time on a marketing department unlike the owners of some other ORMs. Instead we try to be as open as possible about its capabilities and deficiencies and let people decide what they want to use. At the end of the day, all projects have differing requirements and there is no such all encompassing statement of "project XXX is the best choice".

Dan replied on Wed, 2008/02/20 - 11:40am

Your question is meaningless without defining what you mean by "best". Do you want to use the ORM that has the most documentation, the most support, the biggest community, and the largest available set of experienced developers? If so, choose Hibernate. If "best" means something else to you in your particular context, you have to take that into account. "I want the ORM that has the highest speed when dealing with large sets of data, large defined as millions of rows in dozens of tables" or "I want the ORM with the highest level of flexibility in mapping to legacy databases that include stored procedures". Hibernate may or may not be best for those, but you'd have some meaningful way to compare. There is no best tool for every solution. Sometimes Java is the right way to solve a problem. Sometimes Ruby is. Sometimes pen and paper is.

I would be very interested in hearing about those situations where Hibernate is not the best choice, since it is already clearly the best choice in many areas (support, documentation, community).

Rick Hightower replied on Wed, 2008/02/20 - 1:02pm in response to: Andy Jefferson

So in summary, all of the information as to why JPOX should be used is on our website. We don't spend our time on a marketing department unlike the owners of some other ORMs. Instead we try to be as open as possible about its capabilities and deficiencies and let people decide what they want to use. At the end of the day, all projects have differing requirements and there is no such all encompassing statement of "project XXX is the best choice

Well maybe you should spend some time on it. It seems like Hibernate is the de facto choice for many. I remember when Hibernate came out they were pretty direct with their thoughts about EJB CMP/CMR. It is hard to recommend something like JPOX against an established leader like Hibernate. You have to realize the up hill battle some developers will face. BTW I am not endorsing JPOX per se, merely wishing there were some alternatives that could possibly make it past the institutional resistance.

BTW thank you for participating in this thread. It is nice to have an expert voice. I went to your site. I saw your benchmarks. Good stuff.

rick hightowercto of arcMindbloglinkedin

Guido Anzuoni replied on Wed, 2008/02/20 - 1:29pm in response to: Rick Hightower

[quote]

It seems like Hibernate is the de facto choice for many. I remember when Hibernate came out they were pretty direct with their thoughts about EJB CMP/CMR. It is hard to recommend something like JPOX against an established leader like Hibernate.

[/quote]

Well, I would say it is hard convince people, not to recommend other, if you think that other is better.

OK, you back must be strong enough.

Guido 

Jörg Buchberger replied on Wed, 2008/02/20 - 3:21pm in response to: Dan

Dan,

I agree, that one has to become clear about what is needed and then choose the best fit.

I would be very interested in hearing about those situations where Hibernate is not the best choice, since it is already clearly the best choice in many areas (support, documentation, community).

From my experience, I can tune in with some of the voices here and answer this with: iBATIS.

  • It serves us since almost five years in production now, and there were never any significant problems.
  • Where necessary, it was easy to tailor it to our needs.
  • It is really relatively easy to learn and with that I mean, you really do not need to consult the comprehensive documentation much at all.
  • It is more lightweight than the alternatives I know of, with only a couple of third-party dependencies.
  • I cannot say, whether Hibernate is better in the following respects, but we always quickly got helpful support when we needed it and the project makes a stable and healthy impression over the years. The transitions to Apache and to next major and minor releases were smooth and non invasive.

Cheers,

Jörg

Jörg Buchberger replied on Wed, 2008/02/20 - 4:02pm

I found the following job posting trends even more interesting than the ones above...

http://www.indeed.com/jobtrends?q=JDBC%2C+hibernate+java%2C+JPA%2C+JDO&l= http://www.indeed.com/jobtrends?q=JDBC%2C+hibernate+java%2C+JPA%2C+JDO&relative=1

... showing JPA with highest growth rate, but JDBC still in front WRT absolute numbers.
There's of course different ways to interpret this, e.g. that there is high demand for low-level know-how or maybe that JDBC is simply used as short umbrella acronym for all things Java and databases. 

 

http://www.indeed.com/jobtrends?q=database+java%2C+hibernate+java&l=

But one can also see, that according to this numbers, hibernate might be closest to being equated with Java and databases. Impressive.

As for the demand for low-level know-how... 

http://www.indeed.com/jobtrends?q=SQL+java%2C+hibernate+java&l=

SQL still beats them all. So tools that let you deal very nicely with SQL are good to know - e.g. iBATIS that lets you separate Java and SQL, so you can tweak the SQL without need for rebuilding.

 

Jörg 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.