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 by Stephen Duncan Jr on January 25, 2006 at 12:08 PM MST #
Posted by James Strachan on January 25, 2006 at 12:10 PM MST #
Posted by Stephen Colebourne on January 25, 2006 at 12:13 PM MST #
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 #
Posted by Pete McKinstry on January 26, 2006 at 10:28 AM MST #
Posted by Todd Huss on January 26, 2006 at 10:29 AM MST #
Posted by Dave Johnson on January 26, 2006 at 11:31 AM MST #
Posted by Lance Lavandowska on January 26, 2006 at 01:51 PM MST #
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 #
Posted by Erik Bengtson on January 27, 2006 at 03:30 PM MST #
Posted by Andy Jefferson on January 28, 2006 at 10:25 AM MST #
Posted by Gavin on January 29, 2006 at 12:35 PM MST #
Posted by Gavin on January 29, 2006 at 12:50 PM MST #
Posted by Erik Bengtson on January 29, 2006 at 01:21 PM MST #
Posted by Max on January 29, 2006 at 02:02 PM MST #
Posted by Gavin on January 29, 2006 at 10:02 PM MST #
Posted by Gavin on January 29, 2006 at 10:06 PM MST #
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 #
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 #
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 #
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 #
Posted by 83.52.184.172 on January 31, 2006 at 12:09 AM MST #
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:
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 #
Posted by Erik Bengtson on February 01, 2006 at 07:16 AM MST #
Posted by 62.188.31.140 on February 01, 2006 at 09:14 AM MST #
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 #