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
| 131204 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

christiaan_se replied on Wed, 2008/02/20 - 4:43pm

From a comparison point of view, wouldn’t it be nice to have one ORM spec to rule them all? Then you would at least know that the implementation is compliant with a well-thought spec and you could better compare the implementations on additional/optional features, performance (preferably some official benchmark), support, pricing and quality. Now discussions often become blurred by different terminology, different approaches to solve a certain problem and subjective topics.

 

Regarding the job trends, indeed, how to interpret these figures? For one thing, our company never requires JDO expertise for a vacancy, since it can be taught in a few days, really. We rather hire someone with a thorough understanding of OOP or Swing, that is way more difficult to learn.

regards,

Christiaan

Alex(JAlexoid) ... replied on Wed, 2008/02/20 - 5:43pm

My personal preferences go(descending preferability): Hibernate, JPA(OpenJPA/TopLink), iBatis.

But iBatis WINS when having to map objects to basically any contruct in database. I had some mappings to stored procedures, custom types etc... With real ease.... The main problem is that there is nothing like criteria API or query language.

James Bayer replied on Wed, 2008/02/20 - 7:02pm

Disclaimer: I currently work for BEA Systems.

If you want to see some comments from the OpenJPA folks on this post, it's being discussed in their user forum here:

http://www.nabble.com/Why-would-I-choose-OpenJPA-over-Hibernate--to15583130.html#a15590490

Personally I understand that the marketing material for both Kodo / OpenJPA is not as complete and up-to-date as it could be, especially since it lacks the Hibernate comparison. However, given that it is part of the spec now, that alone deserves strong consideration. Additionally, since WebLogic, WebSphere, and Glassfish all either advocate or make it possible to use OpenJPA, you can feel confident that it has the popular app-servers and their vendors / contributors support and confidence.

 

Rick Hightower replied on Thu, 2008/02/21 - 3:13am

Can I get 5 technical reasons to use OpenJPA instead of Hibernate? No. Ok, can you give me 4 reasons to use OpenJPA instead of Hibernate. ... ... Can I get 1 technical reason to use OpenJPA over Hibernate? How about a non-techncial reason? How about a positive experience? No... nothing... thank you.... good night.... frustration!

The best response was from the JPOX guys, and I did not even mention them in the original post. They seem to get it. I have never used JPOX but I admire their ability to state their case. I hope to hear good things about JPOX in the future.

Someone posted a interview with Gavin King which got deleted (not by me but by another moderator--I assume). WOW! Gavin is pretty passionate and technically savvy. He has natural marketing skills! BTW I did not delete it and am not sure who posted the interview (I read it on my blackberry and it was gone before I got here with my laptop). OpenJPA, JPOX, etc. could use someone with that technical marketing capabilities like Gavin. Without that I don't see any of them making inroad into the ever increasing Hibernate mindshare (assuming their technology is worthy of course).

After reading this thread and reading Jonathan's comment thread, it seems Hibernate does really well.  Gavin's responses to Jonathan are very well done if you get a chance, check out the thread. Perhaps this is a case where the herd is right. I just have not seen any compelling arguments to switch to OpenJPA, etc.

TopLink took a bit of a bashing in this thread not by me. Seems no one came out to defend TopLink either.

This response perplexed me.....

(WRT to OpenJPA) However, given that it is part of the spec now, that alone deserves strong consideration.

What do you mean by this? I thought TopLink Essentials was the reference implementation for JPA not OpenJPA. Can you explain this? I use JPA and Hibernate... I am not on any JDO or JPA spec comittee so not an expert on what is and is not part of the spec.

This posts was all about ORMs and a bunch of holigan, iBatis folks break into the party. :o) (see big smiley that says just kidding).

I have actually used iBatis and I do actually like it. I prefer Hibernate for greenfield apps. I also find that Hibernate is pretty flexible with legacy mappings despite the claims to the contrary. There have been times when I have heard that it is not possible to map Hibernate to this XYZ table structure, view, yada, yada... and I was able to do it farily quickly with Hibernate. Get the book. Read the book.  You can do wonders with Hibernate.

However, iBatis sure makes it easy to map to a legacy database, even if the db is a bit whack. It is a good tool to have in the bag of tricks.

For the "just use JDBC crowd", I created a custom course once that implemented a DAO using just JDBC (it actually used Spring's JDBC support which simplifies working with JDBC), then as part of the course the developers rewrote the DAO object using Hibernate (this was before JPA and before so many open source choices for JPA and JDO).

The Hibernate version was a fraction of the Spring JDBC one (it was like a 1/4 or a 1/6 the size perhaps less). It was a lot less code. After this there were few Hibernate detractors. Keep in mind, the JDBC version would have been a lot more without the Spring JDBC support. Hand writing JDBC for CRUD operations is a waste of time in most cases.

Had we been comparing straight JDBC (no Spring helper classes), it would have been a lot larger. Who has got time to hand write all of this?

Sure there are some blind alleys when learning JPA and there is a learning curve, but it seems worth it to me. I work with JPA a lot and really like it. Even on a recent large project, we mostly used JPA and there was only one use case where we used JDBC/SQL instead of JPA.

 

 

rick hightowercto of arcMindbloglinkedin

Rick Hightower replied on Thu, 2008/02/21 - 3:24am in response to: Dan

[quote=pinchworm]

Your question is meaningless without defining what you mean by "best".

[/quote]

I define best as "most advantageous, suitable, or desirable: the best way" similar to the dictionay definition really.  

[quote=pinchworm]  

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.

[/quote]

I can never get paper to compile. I also find that the performance speed of paper seriously lacking not to mention the frequent paper cuts. I don't find Ruby best for anything... I would much rather use Java, Groovy, Python or perhaps sharp ginsu knives! To each his own!

[quote=pinchworm]  

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).

[/quote]

I agree and a big me too. Which is why I wrote this post!

rick hightowercto of arcMindbloglinkedin

Rick Hightower replied on Thu, 2008/02/21 - 3:34am in response to: christiaan_se

Christaan,

Thanks for writing. I have never used JDO in anger. I have used several homegrown ORMs of varying degrees of quality (one even written by me), EJB CMP/CMR 2.x, Hibernate, and several flavors of JPA.

Why do you think JPA has done much better in the market place than JDO?

BTW I am not disagreeing with you and perhaps I will try a JDO flavor of ORM.

"The JDO spec really enables transparent persistency in my opinion." Can you show a short code example or link to one that compares JPA to JDO clearly showing JDO more transparent?

christiaan_se replied on Thu, 2008/02/21 - 8:00am

Hi Rick,

I noticed in my emailbox that some more comments are being posted than displayed here. Some seem valuable comments so I don't know why they don't appear? Anyway, your question on whether a comparison can be found between JPA and JDO can be found here (I believe Andy already mentioned it):

http://www.jpox.org/docs/persistence_technology.html

Some older blog entries which also give some nice insight:http://www.jroller.com/matthewadams/entry/quick_comparison_of_ejb_3http://www.jroller.com/ThoughtPark/entry/ejb3_persistence_an_inferior_standardIf you want to have a quick overview of all the possibilities of JDO2 (like you asked), this quick reference is still very helpful I think:http://www.solarmetric.com/resources/jdo-api-quickref.pdfBtw, the JDO expert group is very active (JDO 2.1 maintenance release is about to launched) and they are very willing to listen to input from the community.kind regards,Christiaan

christiaan_se replied on Thu, 2008/02/21 - 8:01am

Hi Rick,

I noticed in my emailbox that some more comments are being posted than displayed here. Some seem valuable comments so I don't know why they don't appear? Anyway, your question on whether a comparison can be found between JPA and JDO can be found here (I believe Andy already mentioned it):

http://www.jpox.org/docs/persistence_technology.html

Some older blog entries which also give some nice insight:http://www.jroller.com/matthewadams/entry/quick_comparison_of_ejb_3http://www.jroller.com/ThoughtPark/entry/ejb3_persistence_an_inferior_standardIf you want to have a quick overview of all the possibilities of JDO2 (like you asked), this quick reference is still very helpful I think:http://www.solarmetric.com/resources/jdo-api-quickref.pdfBtw, the JDO expert group is very active (JDO 2.1 maintenance release is about to launched) and they are very willing to listen to input from the community.kind regards,Christiaan

Matthew Schmidt replied on Thu, 2008/02/21 - 8:13am in response to: christiaan_se

[quote=christiaan_se]

Hi Rick,

I noticed in my emailbox that some more comments are being posted than displayed here. Some seem valuable comments so I don't know why they don't appear? Anyway, your question on whether a comparison can be found between JPA and JDO can be found here (I believe Andy already mentioned it):

[/quote]

Hi Christian.  You are correct.  Some comments got caught by akismet and I've published them now.

-Matt 

Michael Parmeley replied on Thu, 2008/02/21 - 8:31am in response to: Rick Hightower

[quote]

For the "just use JDBC crowd", I created a custom course once that implemented a DAO using just JDBC (it actually used Spring's JDBC support which simplifies working with JDBC), then as part of the course the developers rewrote the DAO object using Hibernate (this was before JPA and before so many open source choices for JPA and JDO).

The Hibernate version was a fraction of the Spring JDBC one (it was like a 1/4 or a 1/6 the size perhaps less). It was a lot less code. After this there were few Hibernate detractors. Keep in mind, the JDBC version would have been a lot more without the Spring JDBC support. Hand writing JDBC for CRUD operations is a waste of time in most cases.

[/quote]

 

So your students just wrote the DAO object with Hibernate and thought Hibernate was great is not really an argument against the "just use JDBC crowd" (disclaimer: I am part of this crowed). Your students may have changed their tune if you made them figure out how to write the mapping file, how to architect their project so a DB connection can be re-used in the same request, how to get Hibernate to write good performing SQL in an object that has mulitiple collections mappings (this is the showstopper for me). The time they saved writing the DAO would be more than taken up by the above.

With a few clever helper classes that can be packaged in a jar and reused from one project to another I can write JDBC code just as quickly as with Hibernate. Hibernate simply does not save me time.

For anything other than a simple classroom database schema Hibernate is worthless.

Why everyones wants frameworks for everything is really beyond me.

Eric Samson replied on Thu, 2008/02/21 - 11:02am

I think there are important projects in which using Hibernate is not the only solution:

  • When you need to map your business model with several various data sources, not only RDBMS. What I have in mind are transactions running on mainframes (CICS, IMS...), APIs around packaged applications (ERP, CRM, etc.), XML flows of data and Web services considered as new data providers.
  • When you want to use these mappings not only from Java and C#, but also from JBI, SCA, BPEL, workflow engines, rules engines. All these programming-in-the-large BPM environments cannot rely on POJOS or even SQL for data manipulation, they require some sort of Data Services in the middle.

For sure, in this big picture, Hibernate can still be used for strict ORM, but then you will need to combine it with several other frameworks and manual integration in order to address the whole issue. Hibernate did a lot to make ORM popular. But the future is more open than just RDBMS support. This is where, I guess, new products will challenge Hibernate. JPOX is already going in that direction (RDBMS and the db4o ODBMS), as Castor (RDBMS and XML) and Toplink (RDBMS, XML, JCA) as well. IMHO - obviously my opinion is biased ;-) - Xcalia Intermediation Core is, maybe, one advanced and innovating solution when considering mappings which are not limited to POJOs and RDBMS.

Just my 2 cents, Eric Samson. Xcalia.

Rick Hightower replied on Thu, 2008/02/21 - 3:28pm in response to: Michael Parmeley

For anything other than a simple classroom database schema Hibernate is worthless.

Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.

 

Rick Hightower replied on Thu, 2008/02/21 - 3:38pm in response to: christiaan_se

[quote=christiaan_se]

Hi Rick,

I noticed in my emailbox that some more comments are being posted than displayed here. Some seem valuable comments so I don't know why they don't appear? Anyway, your question on whether a comparison can be found between JPA and JDO can be found here (I believe Andy already mentioned it):

http://www.jpox.org/docs/persistence_technology.html

Some older blog entries which also give some nice insight:http://www.jroller.com/matthewadams/entry/quick_comparison_of_ejb_3http://www.jroller.com/ThoughtPark/entry/ejb3_persistence_an_inferior_standardIf you want to have a quick overview of all the possibilities of JDO2 (like you asked), this quick reference is still very helpful I think:http://www.solarmetric.com/resources/jdo-api-quickref.pdfBtw, the JDO expert group is very active (JDO 2.1 maintenance release is about to launched) and they are very willing to listen to input from the community.kind regards,Christiaan

[/quote]

Looks like I have quite a reading assignment. I will try to get to these tonight. I did browse them. Thanks for taking the time to compile the list. 

So if I can just put words into your mouth... In your opinion ORMs that support JDO and JPA are a better pick than those that do not. Seems demand for JPA has matched JDO already....

How can JDO providers be more effective at making their case? Is JDO the beta-max of ORMs and Hibernate/JPA the VHS? Will JDO go the way of Beta-max? Should we all just wait for blueray.... :o)

rick hightowercto of arcMindbloglinkedin

Doug Clarke replied on Thu, 2008/02/21 - 4:36pm

Rick,

First let me clarify where we are with TopLink. The Eclipse Persistence Services Project (EclipseLink, www.eclipse.org/eclipselink) contains the contribution of the full functionality of Oracle TopLink. We will be doing all future work and enhancements to TopLink in open source with EclipseLink.

We had a very good experience with TopLink Essentials which was a subset of TopLink we contributed to open source in 2005 and this positive experience is one of the primary reasons we decided to open source all of TopLink in Eclipse.

EclipseLink offers what we believe to be the best object-relational solution available - implementing JPA with many advanced features including entity caching, additional mapping types and options for interesting/legacy relational schemas, performance optimizations and exposing database vendor extensions. In addition to helping developers access relational data EclipseLink also implements services for other persistence needs including XML-binding, SDO, Database Web Services, and access to non-relational EIS using JCA resource adapters.

Your point of this posting is well taken though, we need to communicate and share better the advantages EclipseLink/TopLink provides and why developers should try it. This is one of the many objectives we have in the near term for EclipseLink.

Doug Clarke

Director of Product Management, Oracle TopLink
EclipseLink Project co-lead
java-persistence.blogspot.com

Rick Hightower replied on Thu, 2008/02/21 - 6:18pm in response to: Doug Clarke

Thanks Doug. Good to hear from you and the TopLink guys.

Guido Anzuoni replied on Fri, 2008/02/22 - 12:14pm in response to: Rick Hightower

[quote=rhightower]

So if I can just put words into your mouth... In your opinion ORMs that support JDO and JPA are a better pick than those that do not. Seems demand for JPA has matched JDO already....

How can JDO providers be more effective at making their case? Is JDO the beta-max of ORMs and Hibernate/JPA the VHS? Will JDO go the way of Beta-max? Should we all just wait for blueray.... :o)

rick hightowercto of arcMindbloglinkedin

[/quote]

The explanation is quite easy to find.

Who are JPA vendors ?

If you were a well-payed consultant of one of these big firms and you should "suggest" technology to your

customer what acronym would spell ? JPA or JDO ?

Expecially if you are not directly involved in the consequences of customers' choices.

(First rule is developers are not good enough if something goes wrong)

 

Cheers,

Rick Hightower replied on Fri, 2008/02/22 - 2:21pm in response to: Guido Anzuoni

Which big firm are you refering to?

 

Mark Unknown replied on Fri, 2008/02/22 - 11:06pm in response to: Rick Hightower

This link is from a guy who has some good things to say about JDO.

http://www.theserverside.com/news/thread.tss?thread_id=47211#241156

Sadly, I think JDO == beta-max. 

Rick Hightower replied on Sat, 2008/02/23 - 2:56am

Thanks for the quote... Steve Zara on TSS wrote....
Politics and practicality. JDO has a very rich set of object states and transitions, and a lot of flexibility. Why would relational database vendors (the majority of those wanting to implement a persistence API) be interested in such flexibility? JPA was probably far easier to implement above existing persistence engines, and was also easier to tie in with the clear market leader - Hibernate.

It is good to get some perspective on this stuff. I haven't worked with JDO (most folks I run into have not either...).

If JDO == beta-max and JPA == VHS... it is good to know that eventually it won't matter b/c we will all be using Blueray in 20 years.... whatever that is. Ha!

rick hightowercto of arcMindbloglinkedin

Guido Anzuoni replied on Sat, 2008/02/23 - 3:40am in response to: Rick Hightower

[quote=rhightower]

Which big firm are you refering to?

 

[/quote]

Isn't Oracle "behind" TopLink ? (BTW, Oracle "promised" JDO compliance when it acquired Toplink)

Isn't BEA behind OpenJPA.

Anyway, any EJB3-compliant container vendor has no interest in JDO promotion.

JPA adresses J2EE env primarly (for whatever it means - really nothing to me -), then it possible to use in ordinary

J2SE apps too, so it is really unreasonable that J2EE-spec-taliban "architects" promote JDO instead of JPA.

In my experience, consultants that design solutions select products putting together google results.

They never, or almost never, have to cope with flexibility, ease of use and other irrelevant features of

the tools they select.

The preferred activity is always the management of the angry customer instead of the implementation of a

serious and professional SW development cycle.

I mean, it is absolutely normal what's happening to JPA.

But, what I'm registering in the last months is an increase number of posts on JPOX forums concerning

the migration to JDO from other JDO impl or from Hibernate.

But, I'm not saying that JDO is better than JPA or Hibernate (no flame war, please), I simply say that spec/products

are different in different areas and differences might be relevant.

When and IF you use what YOU selected as the most suitable tool.

 

Cheers.

P.S.

I'm not a JPOX developer even if I'm an active poster in JPOX forums

Rick Hightower replied on Sat, 2008/02/23 - 4:26am in response to: Guido Anzuoni

Guido if I got one thing from this entire thread, it is this... I should check out JPOX. I will. Thanks all.

 

Andrew McVeigh replied on Sat, 2008/02/23 - 5:39am in response to: Rick Hightower

 Guido if I got one thing from this entire thread, it is this... I should check out JPOX. I will. Thanks all.

 JPOX is very good.  Plus, it can paper over the shortcomings of things like db4o and provide a JDO interface for it.  Heaven knows i found it hard enough to do just that on a previous contract.  Plus the JPOX guys are good people.

 If you are looking for an example of a good OODBMS which uses JDO as its native API also, check out objectdb.com --> i'm a customer and it's a commercial product, but I've been incredibly happy with the performance, consistency, integrity under duress and features.  Gave me faith in OO databases again, after many years of using substandard ones.

 I use objectdb for the CASE tool i've been working on for many years.

 Cheers,
Andrew

 

christiaan_se replied on Sat, 2008/02/23 - 6:12am in response to: Rick Hightower

[quote=rhightower]

Guido if I got one thing from this entire thread, it is this... I should check out JPOX. I will. Thanks all.

[/quote]

 You won't regret it. I also feel that JDO is the beta-max. May be a reassuring thought is that the JDO expert group also focusses on migration from JDO to JPA as can be seen on a quote on http://java.sun.com/developer/technicalArticles/J2SE/jdo/:

[quote]

JDO 2.0 does not propose specific API convergence with EJB 3.0 persistence but rather an evolution of JDO 1.0.2. But the similarities between the POJO persistence model of JDO and EJB 3.0 will enable JDO customers to easily embrace the new EJB 3.0 persistence model while meeting immediate needs with JDO 2.0. In addition, JSR 243 intends JDOQL to be used as an alternative query language with EJB 3.0 persistence. The language has been updated to work better with EJB 3.0.

[/quote] 

 Which is also expressed in a letter to the jdo community and the fact that both JPOX and Kodo support both APIs:

http://java.sun.com/j2ee/letter/persistence.html

So it is not like you have to throw away your beta-max tapes;-) 

May be the JDO community should learn from this thread that we should have better marketing. Rick, how are your marketing skills?

 kind regards,

Christiaan

 

 

 

 

 

Mike Keith replied on Sat, 2008/02/23 - 1:11pm

Rick, I have to admit that I thought (based only upon previous posts) you were already prejudiced towards certain products, but I was apparently wrong (sorry). Kudos for having an open mind.

There are a couple of general points that could and should be said on this thread in and around all of the noise. Obviously IANAM (I am not a marketer) but I still have opinions on this stuff.

I don’t think one should expect web sites to mention Hibernate when they are marketing their own product. A product that promotes itself based on its own great features is in a much better position that simply trying to make another product look bad. Besides, who is going to believe product X criticizing product Y on product X’s web site anyway? Isn’t it going to be just a little bit biased?

I also find it a little sad that the moment that anybody does have reasons to switch from Hibernate that people feel the need to gang up and jump all over him. It’s like they take it as a personal affront or something. Now I don’t know the guy, but he had some valid complaints, found a better way to do things in another product and all some people could do was criticize the features that he was using that Hibernate didn’t have. (Note that TopLink has very many ways to cache depending upon the read/write and isolation constraints of the application so saying that one caching feature configuration is wrong or broken is neither true nor fair.)

Andrew M had a very mixed experience with TopLink. It seemed to have won the competitive evaluation, but at the time (4-9 years ago), it had some issues. It is a known fact that TopLink had product problems during the time that it was mismanaged by the particular company (that no longer exists) that owned it before Oracle, and that it took some time at Oracle to get it back up to snuff. All I can say now is that I know that if Andrew tried EclipseLink (what TopLink has been open sourced as) now he would find not only that it has superior performance, but that it offers all the features and architecture that he expects or needs, plus a ton more.

Being the primary one-stop persistence project in the Eclipse ecosystem is making EclipseLink an attractive choice for other Eclipse projects, and because it is a separate runtime project (and the Reference Implementation for JPA 2.0) that can be used by anyone anywhere it is being adopted by other people as well (such as Glassfish). Being developed in open source means that other committers are welcome, so if somebody has a weird and wonderful requirement that is not already supported then their participation is encouraged.  The experience is open and friendly and the project committers tend to bend over backwards to help people so I really recommend giving it a look (or a second look if you were in Andrew’s position and had a bad experience years ago :).

 

Rick Hightower replied on Sat, 2008/02/23 - 2:18pm in response to: Mike Keith

It is great to get this information about EclipseLink and TopLink. What happened four years ago with TopLink should be less of an issue going forward.

You thought I was biased after I wrote.... "I'd love to see some viable alternatives to Hibernate", Wow! Okay I am a bit biased towards Hibernate but is mostly a comfort zone issue which is mostly due to being mostly familiar with JPA and Hibernate. Who isn't a bit biased? :o)

I have been using Hibernate for over 4 years and I still learn new tricks, and caveats so switching means a whole new learning curve. If I was going to switch, their would have to be a good case why I should switch because even if I decided to switch, I would have to convince others. It just seems the ORM guys are ignoring the elephant in the room. 

The JPA interfaces to Hibernate makes more sense than the original interface. I only use the original interface when I need to use a featue that does not exists in the JPA interface. I find standards a good thing especially when it means improving on what is already there. Also, Hibernate usage has gone up after JPA was adopted so if anything, it made Hibernate not just the de facto standard but the leading implementer of the standard. At the same time, it did level the playing field so I hope to see some viable alternatives. Competition is good for technology.

The TopLink/EclipseLink guys are well represented. The JPOX guys are also well represented. The ones I was truly reaching out to (OpenJPA).... are only slightly represented... even after taunting and begging. I wrote one email to their mailing list wrt to this post. I wrote one email to Patrick as well. I guess they are just too busy.

I'd love to get 5 reason from each ORM why they think people should switch to their ORM from Hibernate, but alas... it is unlikely to happen.

Heck even the "JDBC rocks crowd" and the iBatis guys are well represented and they were not even invited to the party (although we enjoy their comments).

Oh yeah... one more thing... we did not get so much as a peep from the Cayenne guys either...

rick hightowercto of arcMindbloglinkedin
 

Andrew McVeigh replied on Sat, 2008/02/23 - 4:43pm in response to: Mike Keith

Andrew M had a very mixed experience with TopLink. It seemed to have won the competitive evaluation, but at the time (4-9 years ago), it had some issues. It is a known fact that TopLink had product problems during the time that it was mismanaged by the particular company (that no longer exists) that owned it before Oracle, and that it took some time at Oracle to get it back up to snuff. All I can say now is that I know that if Andrew tried EclipseLink (what TopLink has been open sourced as) now he would find not only that it has superior performance, but that it offers all the features and architecture that he expects or needs, plus a ton more.

 

(Mike, I presume you work for oracle? Disclosure would be good if that's the case. For my part I am a consultant working in financial services for inv banks in London. I have no commercial links to any database company, although I routinely use Oracle and SQLServer amongst other products in my work)

Perhaps you can update us with info on how toplink manages the cache now?  At the time I stopped using it in early 2005 (having used it for 5 years more or less continuously) it still had a single cache per session which was shared by multiple units of work. It was possible to set it up to use a session per unit of work (and the 3 tier configuration using multicast) but the fact remained that it was very difficult to handle the different types of data caching (reference data, transactional data) differently. At the time oracle provided some g-d-awful workaround which trawled through the cache looking at the read-only flag on the descriptors and selectively removing parts of the cache. The company in question grappled with the complexities of this for many weeks under multi-threaded conditions. I can only hope the situation has improved and that you can point us to the documentation that demonstrates this... I hope that no project has to go through the contortions we did to handle a very common scenario.

Yes, toplink won the competitive evaluation (in hindsight, hibernate was not mature enough) but this certainly benefited from my in-depth use and knowledge of it in previous projects. The JDO PoC (Kodo) was performed by one of the members of the JDO JSR group, and at the time I was struck by how elegant and simple the JDO queries were given that the toplink query language was so esoteric and poorly documented. Interestingly, the Hibernate PoC was done by another person who has since become very well known for his practical and elegant approach to these enterprise problems. In hindsight I wished i had pushed one of the other solutions, certainly the toplink PoC was failing before I got involved. The actual key point behind the decision turned out to be a (slightly) misguided management belief that if it was from oracle then it was superior somehow...

As an aside, I'm irritated by your contention that "that I know that if Andrew tried EclipseLink... now he would find not only that it has superior performance, but that it offers all the features and architecture that he expects or needs...". Perhaps I would, who knows. However, either speak specifically to the facts, or indicate how you know this information...  Not to put to fine a point on it, please do not claim to speak for me.

Andrew

 

Mike Keith replied on Sat, 2008/02/23 - 9:31pm in response to: Andrew McVeigh

Yes, Andrew, I work for Oracle. Sorry. Most people that follow Java persistence know who I work for so disclosure is not usually an issue.

If you are interested in reading about the kinds of features that EclipseLink has added and formalized over the last 5 years I would by all means encourage you to browse the docs.  I won't brag that they are the best docs in the world, but I think and hope that they are better than what you used last time. If you still have suggestions then I'm sure the doc writers would be happy to get feedback.

From your description it sounds like an isolated client session would have fit your purpose nicely (see http://www.oracle.com/technology/products/ias/toplink/doc/11110/devguide/sesun.htm#CACBHIIA). EclipseLink supports configuring instances of different classes to be either stored in the shared cache, or completely isolated and never stored in the shared cache, so you can declaratively configure based on different isolation requirements.

The transparency issue you mentioned was a holdover from the days when many companies actually had strict requirements for not having domain classes enhanced or tinkered with. In this current era of AOP, weaving and proxying it is a non-issue and nobody (EclipseLink or any other ORM software that I know of) requires that kind of vendor class in the object model.

I am not sure how you got the impression that I tried to speak for you. I simply made the statement that you would be able to find in EclipseLink the features and stability that you claimed were missing 5 years ago (i.e. the items that you mentioned in your post). I assumed that you listed the things that you were unhappy with and that you were happy with the rest, so the sum total would equal the features that you "expected or needed". If you had additional needs that you didn't mention, well, I can't (and wouldn't) comment on those without knowing them. 

If you have an axe to grind, then I am not one to try to get you to put it away. You have already stated that you would never go back to TopLink so I am not sure if you are really interested in the answers to your questions, but I am willing to help anyone who sincerely does, or is interested in trying out what I believe is currently the most powerful persistence software available.

Ashley Aitken replied on Sat, 2008/02/23 - 10:39pm


Would anyone like to comment on the implications (or guess the results) that Oracle buying BEA has for OpenJPA and EclipseLink going forward? Of course, they are both open source projects so they have a life of their own, but is Oracle going to support the primary development of both project? It would also seem that they have quite different backgrounds (OpenJPA from Kodo/JDO and EclipseLink from TopLink proprietary API) so that merging may not be that useful or easy, if this is ever considered. Apologies and please correct me if I am wrong on anything here (the open market of standards and implementations is difficult to keep up with when there are mergers and buyouts). Cheers,Ashley. 

Andrew McVeigh replied on Sun, 2008/02/24 - 5:45am in response to: Mike Keith

I work for Oracle. Sorry. Most people that follow Java persistence know who I work for so disclosure is not usually an issue.

Disclosure when talking about something you are commercially involved with is the wise option. This is javalobby, not the JPA forum.

EclipseLink supports configuring instances of different classes to be either stored in the shared cache, or completely isolated and never stored in the shared cache, so you can declaratively configure based on different isolation requirements.

Sounds like it might address that issue. Do you have object identity preserved over the unit of work (i.e. if i get the same instance via a query twice in the unit of work, then it is guaranteed to be the same object (i.e. ==)) even if caching is turned off for transactional data?

How about the old "conformResultsToUnitOfWork" option that was very slow and didn't work properly (i.e. didn't support all query types)? Do results now authomatically sync with the new objects in the pre-comit cache? Can you use coherence (or terracotta ;-) as the backing store for a shared cache?

I am not sure how you got the impression that I tried to speak for you.

It was the statement "I know that if Andrew tried EclipseLink ... now he would find not only that it has superior performance, but that it offers all the features and architecture that he expects or needs" (emphasis mine). i.e. You know that I would find toplink more performant (than what??) and with all the features I need? Heck, i don't even need to evaluate it, you already know! This sounds like marketing speak, and i am wary enough of that from enterprise vendors.

If you have an axe to grind, then I am not one to try to get you to put it away.

Don't take it personally. I have a (healthy) level of disdain towards enterprise vendors who tell me that their product will solve every need, despite previous findings that it didn't. Based on my experience with toplink over its many generations, my caution is warranted. Certainly i dealt with oracle for perhaps a year after they owned the product.

You have already stated that you would never go back to TopLink so I am not sure if you are really interested in the answers to your questions, but I am willing to help anyone who sincerely does

I don't like this sentence. Again, you are trying to summarise my intentions, and are implicitly accusing me of being insincere. My comment was "Based on what i've experienced, i would never go down the toplink route again...". I'm not coming out with this stuff out of thin air -- i used to be the biggest toplink supporter around and have been let down. Speak to my experience or discuss how the product has improved, or try to convince me through technical arguments. Heck, tell me what i offers over and above Hibernate. Ad homeneim attacks are not the way to persuade me.

Let me clarify for the record -- i'd use toplink but only behind a non-proprietary API (JPA or JDO). As long as it could be substituted for another product if it were found to be deficient, i'd consider it again. I'd strongly recommend that others do the same based on my experience -- avoid binding yourselves to proprietary toplink APIs or features.

(By the way, whatever happened to the commitment to support JDO? We got this commitment at some point (possibly even pre-oracle) and it had moves to go this way, but eventually the JDO stuff was deprecated)

Andrew

 

Mike Keith replied on Sun, 2008/02/24 - 4:23pm in response to: Andrew McVeigh

[quote]Disclosure when talking about something you are commercially involved with is the wise option. This is javalobby, not the JPA forum.[/quote]

Actually this is an ORM thread on JavaLobby and an ORM thread in any forum tends to involve the same people (most of whom already know each other!). Anyway, I think it was pretty obvious that I was associated with the project, and if people want to know who I am they can always google me.

To answer your questions, yes, the isolated cache does maintain identity whether the classes are in the shared cache or only in the isolated session. Yes. the conformResults option is still there, and no, it is not slow or broken. In-memory queries are a means of optimizing a certain subset of queries and for those cases issuing the query in memory is going to be faster than making a round trip to the database. Making it work for all queries would involve writing another query engine and I don't think anyone thinks that is right answer. Again, this a feature that few other implementations even try. Most just go ahead and flush to the database and query the database to get the results. This feature saves that database access cost for many cases, but admittedly not all, though.

[quote]I don't like this sentence. Again, you are trying to summarise my intentions, and are implicitly accusing me of being insincere.[/quote]

You seem to be a mix of grudge and sensitivity all rolled up into one ;-) Maybe it's just me, but anyone who just bashed a product based on a 5-year old version (during its most troubled times, I might add again) and said they "would never go down the ... route again" is not going to be "sincerely interested" in the product. Sorry if you take offence at that, cuz I wasn't meaning to be offensive, but I only assumed that you meant what you said the first time. I would be happy if you didn't, though, and more than willing to spend more time with you offline to show you what EclipseLink can do.

[quote]Speak to my experience or discuss how the product has improved, or try to convince me through technical arguments. Heck, tell me what i offers over and above Hibernate.[/quote]

I was doing preceisely that -- addressing your previous concerns and explaining how things have changed for the better. If you are sincerely interested (and before you take offence note that I am neither attributing sincerity nor insincerity to you, only making a conditional statement) then feel free to contact me or anyone else on the EclipseLink project and we will be happy to answer any questions that you may have.

[quote]i'd use toplink but only behind a non-proprietary API (JPA or JDO). As long as it could be substituted for another product if it were found to be deficient, i'd consider it again. I'd strongly recommend that others do the same based on my experience -- avoid binding yourselves to proprietary toplink APIs or features.[/quote]

Does this mean you have had a slight change of heart? ;-) I actually mostly agree with you, though, about using JPA regardless of the ORM products you are using. Whether you use TopLink or Hibernate or any other implementation, using JPA just makes portability sense. When additional features are needed then people may need to turn to proprietary APIs, as long as they are kept isolated and not scattered across the application. 

[quote](By the way, whatever happened to the commitment to support JDO? We got this commitment at some point (possibly even pre-oracle) and it had moves to go this way, but eventually the JDO stuff was deprecated)[/quote]

I am not aware of any customer commitment to supporting JDO. For a time there was a partial JDO implementation that got shipped with the product, but it was only a portion of the API and I only know of one customer that ever used it. Once it became clear that JDO was not going to be mainstream and that JPA was going to be the blessed enterprise API moving forward then resources were allocated to implementing that API. Without customers using it or asking for it there was no reason for the JDO implementation branch to even continue.

Comment viewing options

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