Matt RaibleMatt Raible is a Web Architecture Consultant specializing in open source frameworks.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Does JPOX suck?

There's an ongoing effort in Roller to migrate from Hibernate to JDO. Mostly, this is due to Apache's silly rule about no L/GPL dependencies - even if they're downloaded separately. I think this is a valiant effort, especially if JDO performs as well as Hibernate.

However, it was interesting to see the following message on the mailing list this morning:

i have experience using jdo, and jpox in particular, with a commercial product. first, you probably already know this, but jdo is dead (from a spec perspective anyway). it will be phased out in favor of ejb3 persistence. maybe that transition will be graceful, maybe not. i see jpox has ejb3 on their roadmap, but not sure what that means.

second, jpox has really, very atrocious performance issues. the jpox folks admit that performance is a low priority, as they are an ri. if someone wants the details on this, i can dig them up.

Interestingly enough, this message is from a Sun employee. It's interesting to hear someone from Sun say that "jdo is dead". What are you thoughts? Should Roller change their persistence backend just to satisfy Apache?

Of course, now you'll tell me your favorite Apache-licensed persistence framework and why it's worked so well for you. The real question is - are you willing to re-write Roller's backend using it? ;-)

Posted in Java at Jan 25 2006, 10:57:56 AM MST 31 Comments
Comments:

I can understand no GPL dependencies, but no LGPL dependencies? That does seem quite silly.

Posted by Stephen Duncan Jr on January 25, 2006 at 12:08 PM MST #

Dunno why Roller doesn't just use JPA (EJB3 persistence) that would let them deploy on hibernate but compile against a standard JSR API

Posted by James Strachan on January 25, 2006 at 12:10 PM MST #

Maybe if people actually read the LGPL rather than assuming it means what they think it means people would understand. Put simply, LGPL is an unclear, badly worded licence that is wide open to varying interpretations. Apache, and many companies, just don't accept LGPL because of this lack of clarity.

Posted by Stephen Colebourne on January 25, 2006 at 12:13 PM MST #

I use Hibernate too... :( What about Cayenne (http://www.objectstyle.org/cayenne/)? It has an Apache-style license... It seems good but I've never tried it.

Posted by Davide Savazzi on January 26, 2006 at 03:59 AM MST #

Firstly, the fact that OJB isn't being treated as an obvious choice (it being an apache project that covers almost exactly the same space as Hibernate) is a pretty poor indictment. I've never met anyone who uses OBJ, so I guess it either has a really poor implementation, or really poor marketing (or both).

Secondly, I agree with Stephen Colebourne - the LGPL problem is real. The intention might be fine, but the language doesn't work. It was written assuming a C-style static/dynamic linking model, and the language shows it. I can't find any way to read it that actually fits the java runtime model. Now that's OK for most people, since it's fairly clear what JBoss/Gavin/etc's intention is for the licensing, but it doesn't work if you're trying to provide packages that businesses can rely on with legal certainty (which is one of Apache's goals)

e.g. The 2nd paragraph of point "<tt>0</tt>" is:A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. Java programs aren't "linked ... to form executables", so the whole license fails straight away since one of the core definitions can't be applied.

I don't expect anyone will ever be sued for using Hibernate in a closed application. It's clearly the JBoss group's intention to allow that. But Apache prides itself on being legally "pure", so for them the actual legalities of the wording do matter.

Posted by Tim Vernum on January 26, 2006 at 04:41 AM MST #

Although it was a few years ago, I used OJB for persistence in a fairly large java reporting system and had good success with it. I'm not sure why they aren't considering that as a choice for the replacement of the jroller backend... It's been swept to the side by the success of hibernate in the last few years though. (obviously) If you read back through the apache mailing list logs, you'll find that they (i.e. their lawyers) did a lot of due dilligence on the LGPL license and decided it was not compatible w/ ASL... For exactly the reasons Stephen stated. The license itself does not make clear how & when you can re-use LGPL code in code not licensed in the same way.

Posted by Pete McKinstry on January 26, 2006 at 10:28 AM MST #

Matt, I second James. Why wouldn't Roller go with EJB3? It has a very promising future and will allow the most flexibility going forward in terms of easily switching out the underlying implementation.

Posted by Todd Huss on January 26, 2006 at 10:29 AM MST #

The Roller team has not chosen JDO and is certainly not ignoring EJB3 or any other option. We have "issues" with Hibernate and would like to investigate alternatives. Craig Russell, the architect of JDO, volunteered to do a JDO implementation for us and we'll evaluate it when he's done.

Posted by Dave Johnson on January 26, 2006 at 11:31 AM MST #

To echo Dave, OJB isn't being used because no one volunteered to implement Roller's backend using OJB. Nor has anyone volunteered to implement EJB3, otherwise I like James' suggestion.

Posted by Lance Lavandowska on January 26, 2006 at 01:51 PM MST #

I have no experience yet of JPOX performance, but I am about to use it in the development phase of a project, so I should soon find out. I have had reasonable performance from a range of JDO implementations which seem to have been equivalent in features and optimisation options to JPOX, and as JPOX is currently emphasising performance in the announcement of their latest release, I don't expect significant problems. Time will tell. As for comments suggesting using EJB3.0 - it certainly looks good, but it is still a subset of JDO in many significant respects. The way ahead should be to put further effort into unifying JDO and EJB, so that a future persistence architecture is a superset of these APIs. There was some effort to discourage use of JDO last year with the vote against JDO 2.0, but the response to that showed that JDO is far from dead (at least for now), so I don't take the comment from the Sun employee that seriously.

Posted by Steve Zara on January 26, 2006 at 09:40 PM MST #

To clarify; it's not Apache's silly rule about LGPL, it's the legal advice Apache received concerning LGPL. So rather than seeing the usual split on whether LGPL is a well written licence or not, I'd like to hear what everyone's lawyers say :)

Not that I disagree with you for seeing it that way; like many things at Apache it's tribal knowledge rather than written down rule, and tribal knowledge always seems silly when it gets in the way. There's a lot of work to codify these kinds of legal issues so everybody understands the exact position - hopefully that will bear fruit soon - which can only be to Roller's benefit. Whether it ends up being yea, or nay, we'll be on firm ground as to what needs to be done.

Posted by Henri Yandell on January 27, 2006 at 08:54 AM MST #

give JPOX props http://www.jpox.org/docs/performance.html

Posted by Erik Bengtson on January 27, 2006 at 03:30 PM MST #

To reiterate the link Erik just posted, this shows JPOX outperforming Hibernate on the PolePosition benchmark. It completes the tests in a sixth of the time Hibernate needs. Attrocious ? Please judge for yourself ;-)

Posted by Andy Jefferson on January 28, 2006 at 10:25 AM MST #

Oh give me a break. Poleposition is an utterly bogus benchmark created by the db4o guys to try and push their product. If you are going to try and tout numbers, use something at least one quater credible. please.

Posted by Gavin on January 29, 2006 at 12:35 PM MST #

By the way, isn't it truly special when one vendor (JPOX) quotes their hand-optimized results on a benchmark written by a second vendor (db4o) which purports to show slow performance of a third vendor (Hibernate) who never had any involvement or chance to optimize the benchmark results for their product. To get results that bad on any benchmark, you would need to hand-deoptimize Hibernate, and presumably that is what has been done here. Of course, neither vendor mentions this fact and tries to pretend that the benchmark is some kind of totally independent unbiased thing. The dishonesty of both these groups is frankly astounding to me.

Posted by Gavin on January 29, 2006 at 12:50 PM MST #

Gavin, We are not making false advertising or being dishonest. They are true results from a benchmark, which you can contest, but then provide your own Hibernate configuration/changes, and we run the benchmark again. If you point us a benchmark endorsed by your team, we will love to run JPOX against it.

Posted by Erik Bengtson on January 29, 2006 at 01:21 PM MST #

http://www.gnu.org/licenses/lgpl-java.html

Posted by Max on January 29, 2006 at 02:02 PM MST #

Sorry, Erik, I simply don't have time to waste on reacting to every lame attempt by competitors to show Hibernate is bad and their stuff is better. In terms of usage, neither JPOX nor db4o register as a blip on the radar, so why would I bother taking time out from all the important things I have to do to counter this nonsense? Fact is that by representing poleposition as "independent" on your website, you are being clearly dishonest, since it is clearly a vendor benchmark. Your credibility should be judged on that basis. I have no time for this kind of behavior, and frankly you should be ashamed of yourself.

Posted by Gavin on January 29, 2006 at 10:02 PM MST #

By the way, The One True Benchmark is that hundreds of thousands of people are using Hibernate in real production systems, and yet we never hear complaints about performance from real users. If Hibernate performance was truly as bad as claimed in this totally bogus vendor benchmark, we would be seeing problems in production. We don't. QED

Posted by Gavin on January 29, 2006 at 10:06 PM MST #

I have seen this pattern repeated in many forums over the years although I haven't seen it for a while. I thought Gavin had given up on his abusive, insulting, rude and aggressive, multiple entry responses, possibly because he believed that Hibernate's position was so cemented in the future of Java persistence that he had no need fend off any more "attacks" like a 10 year old school yard bully. It appears his definition of an attack is: someone saying something positive about an alternative persistence technology or a benchmark that shows that Hibernate isn't necessarily the fastest persistence technology.

Part of my initial resistence to using Hibernate was not a technical one but rather a reaction to Gavin's posts - did I really want to use software created by someone with that sort of attitude? But, because "so many people are using it", I overcame my inhibitions and used it. It wasn't until later that I switched from Hibernate to JPOX for technical and arhitectural reasons - and the performance is more than fine.

Come on Gavin, as a fellow Australian it's my duty to tell you that your posts often make it appear like you're not a "happy little vegemite" (sorry, that's an Aussie thing) but there's no need to worry - there's room in this world for alternatives to Hibernate so "chill out man" your baby's going to be fine!

"By the way, The One True Benchmark is that hundreds of thousands of people are using Hibernate in real production systems" -- Gavin

Using that argument MS-DOS was the best operating system ever created... As we all know from the Microsoft experience market penetration can be a great substitute for innovation, performance, good engineering and sound architecture - so be careful using the above as a consideration when making a technical/engineering decision about which persistence technology to use.

Please don't take this post as a criticism of Hibernate, in fact our Javelin object modeling -> code tool (http://stepaheadsoftware.com/products/javelin/javelin.htm) automatically generates, from a visual class model, mapping files for Hibernate or one of the many JDO implementations (open source and commercial), including JPOX, so in one sense we are "persistence technology agnostic". Javelin users can see how their apps work using one persistence technology and then flick a switch to generate mapping files for another persistence technology and see how it works with that. So in the end Javelin users can use the technology that's best for their particular project and avoid "vendor lock in" which can happen even in the open source world - so be careful!

Oh yeah, JDO is not dead - it's truly alive and kicking no matter how much many people with secret agendas would like it to be otherwise.

Posted by Chris Colman on January 30, 2006 at 04:50 AM MST #

Chris, the difference is that when I promote things I create, I don't do it by saying negative things about other people's products. Why can't these people simply keep our name out of their mouths? Nor am I dishonest and eg. misrepresent a vendor benchmark as independent, or publish nonsense benchmarks showing a competitor's product is 10x slower than mine. Yes, I'm aggressive in dealing with people who do either of these things. I will continue to be. I'm not in the least bit bothered if *you* don't use Hibernate because of that. I know that very, very few people make technology decisions on the basis of personalities :-) I also know that if *you* had to deal with the kind of crap that we have to deal with, you would respond quite similarly. Of course, you have never been in this position.

P.S. If the millions of people using MS-DOS where using it happily and not experiencing any problem with that, then there would be no reason to switch. The difference is that MS-DOS users were unhappy. Since the only reason you have shown why you have been unhappy with Hibernate is my *personality*, that does not seem to be the case in this case.

P.P.S. Regarding vendor lockin - have you heard of EJB 3.0? You should check it out.

Posted by Gavin on January 30, 2006 at 09:03 AM MST #

Well, I said earlier I had no experience of JPOX performance. I do now. I have to say I am not happy with it. I was looking at it as an alternative to commercial JDO implementations (and also because it will be the RI for JDO 2.0). Unfortunately for my applications JPOX is running at a fraction of the speed of commercial alternatives, and has memory problems that don't seem to be present with other JDO implementations I have tried. I found this rather disappointing, as a quality open-source JDO implementation would have been very appealing. This also leads me to doubt the usefulness of the benchmarks shown on the JPOX website.

I have seen many good reports of Hibernate performance, and I have no reason to doubt them. So, if the alternatives were JPOX and Hibernate, I would certainly attempt to stick with Hibernate.

Posted by Steve Zara on January 30, 2006 at 01:46 PM MST #

"P.S. If the millions of people using MS-DOS where using it happily and not experiencing any problem with that, then there would be no reason to switch. The difference is that MS-DOS users were unhappy." - Gavin

Yes but at the time better alternatives to MS-DOS costed a heck of a lot more so there was effectively no viable alternatives. In the open source world alternatives are free and new ones pop up relatively frequently which may explain why you feel the need to be so aggressive against alternatives. With "free" technologies people can choose a different one with each new project because they don't have to explain to the bean counters why they aren't using the technology that the company paid $150,000 for a year before. (a current example of this seems to be the massive exodus of developers from JSPs who are trying a myriad of different, next generation, component based, AJAX enhanced Web UI technologies - which is a healthy thing)

"Since the only reason you have shown why you have been unhappy with Hibernate is my *personality*, that does not seem to be the case in this case. - Gavin

I know that you don't have much time because you've got many more important things to do but if you had time the time to read what I actually wrote you'd realize that I didn't say that peronality was the reason why I switched.

BTW the issue isn't the face value of a technical lead's personality. At face value I wouldn't care if you were Saddam Hussien. Rather the problem is one of product development and improvement. I've worked in projects with a dominant, aggressive lead in which everyone else's suggestions count for nought, every possible idea for improvement is interpreted as a personal attack and consequently shot down in flames with religious arguments rather than technical ones and the long term success of the project suffers as a result. These team leads usually ends up losing intelligent, challenging team members and attracting non threatening types who don't rock the boat and who aren't known for pushing the technological boundaries and consquently innovation suffers and the product never ends up being what it could be.

I trust/hope that the attitude you exhibit in forums gets left at the door when you enter a meeting with other Hibernate developers.

Posted by Chris Colman on January 30, 2006 at 03:51 PM MST #

With "free" technologies people can choose a different one with each new project

And this is utterly a Good Thing, and one of the things that forces us to keep improving our product and staying ahead of the competition. By the way, I have absolutely no problem with competition; indeed, I live off it. But being competitive doesn't mean bashing your competitors.

I've worked in projects with a dominant, aggressive lead in which everyone else's suggestions count for nought, every possible idea for improvement is interpreted as a personal attack and consequently shot down in flames with religious arguments rather than technical ones and the long term success of the project suffers as a result. These team leads usually ends up losing intelligent, challenging team members and attracting non threatening types who don't rock the boat and who aren't known for pushing the technological boundaries and consquently innovation suffers and the product never ends up being what it could be.

Chris, I havn't asked them, but I'm guessing that the Hibernate team would not describe me in exactly these words. ;-) You've never met me, nor corresponded with me, so I guess you have no idea how I conduct myself in dealing with people who are making active positive contributions to the project. Why on earth would you think that I would interact with my own team in the same way I interact with competitors I feel are being dishonest in their claims about my product? That makes no sense, surely?

Incidentally, Steve Ebersole now leads the Hibernate project, not me.

Posted by Gavin on January 30, 2006 at 09:15 PM MST #

To Steve Zara, JPOX is actually very configurable for performance if you just try it. You don't seem to want to try, or ask for help. There are lots of documents telling you how. I switched from Kodo to JPOX and have no issue with its speed. JPOX I think was written by just 2 people, and the least you should do is give them a chance.

Posted by 83.52.184.172 on January 31, 2006 at 12:09 AM MST #

I have put considerable effort into attempts to re-configure JPOX for performance, based on documents on the JPOX site. As for giving people a chance, I would like to, but I have projects in development that need to progress, and - sadly - it is often more cost effective to pay for commercial products that provide performance than to spend time on such matters. However, the advantage of standards such as JDO 2.0 (and EJB 3.0) is that I can easily give JPOX another try if there are any indications that things have improved.

Posted by Steve Zara on January 31, 2006 at 04:06 PM MST #

You mention a very good point about JDO - it being a standard means that you can swap and change between implementations easily.

Plus: if you're a person that believes that round pegs fit into round holes better than square holes then you can see that storing objects in an object database is intuitively more efficient than using an object relational mapper. At the moment we all need to use Round (Object) to Square (Table/Row) Converters (Object Relational Mappers) becauase RDBMSes are the current mature technology but IT is a constantly moving, morphing, improving beast and it's only a matter of a time before Object Databases will be at a level of maturity, availability, feature set and price to rival relational databases.

So whenever this happens, and it's as inevitable as OO itself was (even with all of its detractors at the time), a JDO based solution will easily take advantage of such technology when it reaches critical mass whereas solutions based on solely ORM technologies that have not abstracted the storage functionality to a sufficient depth via the use of a generic interface in their architecture won't be able to make this crossover. I suppose that's why JDO is intelligently referred to as a persistence management standard (of which most implementations are currently ORMs but they could be anything - including future things not even thought of yet) whereas most non JDO solutions (of which there are many) are referred to as pure ORMs.

If I were a relational database vendor I would be regularly dropping lines like "JDO is dead". I'm not saying that they are doing this but I certainly would be if I was an RDBMS vendor: It's a perfectly normal self preservation statement. I'd be steering developers towards solutions that provide no possible path to an object database solution now or in the future. In that sense JDO is a lot more open than other solutions like EJBs and therefore a possible threat to the stranglehold that RDBMSes have on the IT world. Please don't think of me and an OODB zealot - don't get me wrong - I use many different relational databases right now but I like to build solutions for my customers that are flexible way into the future. It's like buying a PC with a USB port - I don't know what USB devices might come along in the future but it's nice to know I'll be able to plug them into my PC and "voila!" they just work without rebuilding the PC because USB is a standard and I can plug anything that conforms to that standard into the socket and start using it.

Remember the 80s and early 90s when some IT corporates aimed to lock customers into their proprietory technologies. Customers got badly burned but out of the ashes arose "Open Standards" to keep everyone honest - well as always it pays to remember history! A similar "lock in" could arise, not at the level of an individual vendor's product but at a technology level - in this case the RDBMS. Newer technologies could arise (remember RDBMS technology has been around for many decades now) that may perform better or allow you to handle mega sophisticated object models faster, or class/schema migration automatically or give you ice cream on tap or whatever, but your choice of persistence technology now could either enable or disable your ability to use those new techologies as they arise.

Just a note on open source/open standards: it would not be prudent to confuse "Open Source" with "Open Standards". There are "open source" implementations of "open standards" and then there's "open source" implementations based on no standard or a proprietory interface (published or embedded - ie., read the source code).

Posted by Chris Colman on January 31, 2006 at 07:57 PM MST #

"I have put considerable effort into attempts to re-configure JPOX for performance, based on documents on the JPOX site." - Steve Zara

Steve, if you want to play around with different configurations in JPOX to test their performance then you might want to try using our Javelin class modeler/coder product (15 day eval) which supports JDO and Hibernate. You can visually create your object model in a UML like class diagram. It generates, on the fly, class files (the method bodies inside can be externally edited without losing sync) and JDO (various implementations, including JPOX) or Hibernate mapping files.

For both JDO and Hibernate options you can select various inheritance strategies at both the class diagram level (applies to all classes) or the individual class level:

  • vertical (table per class)
  • flat (table per class hierarchy)
  • horizontal (table per concrete class)

In my experience the inheritance mapping strategy plays a huge part in the performance. To be able to flick easily between the different strategies will give you an insight into what performs well and what doesn't with your particular object model. If you have deep inheritance trees you can decide to choose a point midway in the tree and map everything from that point down into its own table. Basically you can have a play and see what works well.

The 'table per class hierarchy' strategy seems like the most normalized and hence possibly an intuitive choice at the beginning but the SQL joins required to assemble an object from many different tables can be expensive.

You can download a fully working Javelin trial from our website: http://stepaheadsoftware.com/product/javelin/javelin.htm As always we'd love to hear any feedback you have.

Posted by Chris Colman on January 31, 2006 at 08:23 PM MST #

Steve, We would love to help you in sorting out the performance issue with JPOX. Would you care to file a issue presenting the scenarios where you note the problem? One hidden JPOX setting not described in the performance page which can make a lot of difference is the JDO reachability mechanism. Try disabling it org.jpox.persistenceByReachabilityAtCommit http://www.jpox.org/docs/1_1/pmf.html

Posted by Erik Bengtson on February 01, 2006 at 07:16 AM MST #

Steve, We would love to help you in sorting out the performance issue with JPOX. Would you care to file a issue presenting the scenarios where you note the problem? I will.

Posted by 62.188.31.140 on February 01, 2006 at 09:14 AM MST #

It seems to me that benchmarking is the key thing. So far I have not seen a benchmark where Hibernate wins. All I ever see that the Hibernate team dismisses the findings because the Hibernate test setup was unfair. I think the Hibernate team should try and prove it's performance by some measure or another at least once before saying that it doesn't have time to prove it against every little contender's protest.

Maybe if I used straight JDBC that I could be needing 1/25th the amount of server power. That is a great consideration to skip the whole EJB3, JDO, Hibernate thing altogether! Microsoft's approach seems to be sensible in this regard. ADO.Net makes working with Datasets easy and doesn't seem to incur a 25X penalty.

Or maybe the 25X penalty for Hibernate isn't real. How is anybody supposed to know?

Posted by Tim Edwards on May 30, 2006 at 03:57 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed