Sometimes you just have to look at the way things shake out and think, “I win.” This happens to me so very rarely that this feling is utterly alien to me, but I can now tell you that it feels pretty good. After years of writing my own code to copy values in Java objects to relational databases, I realized that I needed to take a good hard look at what was out on the market and see if I couldn’t simplify my life.
There were a lot of object-relational tools out there, everything from TopLink to Castor to EJB’s entity beans, to the standards-driven JDO.
After a very unscientific survey of the market, I chose Hibernate. It seemed like a good choice to me because I could understand how it worked without reading a whole lot about it, because it didn’t require anything but including a few libraries with your application, and because it had good XDoclet support.
As it turns out, the people deciding how EJB 3.0 should work
agreed with me. I read an EJB book last year and found persistence as defined in EJB 2.0 to be horrifyingly complex. Apparently, the EJB 3.0 expert group agrees with me, as they’ve chosen Hibernate 3.0 as the persistence implementation for EJB 3.0. For me, that’s great news. I already know Hibernate really well, and am quite fond of it, so this puts me ahead of the curve for once. Supporters of other options are not so pleased. The author of the column, a JDO proponent (I wanted to like JDO, I really did, but the timing wasn’t right or something), is quite bitter about the whole situation. Unfortunately, he’s ignorant when it comes to Hibernate:
IBM and Oracle are two major players in the EJB app server space that one would expect to be at least leery of the EJB 3.0 expert group’s choice. However, as database vendors also, they probably prefer Hibernate to JDO because it uses the SQL syntax of the underlying RDBMs–which allows applications to be locked in to a specific database vendor. Members of the JDO community suspect that JDO’s portability across databases–preventing vendor lock-in–is a primary reason for IBM and Oracle opposing JDO. Maybe these vendors are willing to concede a portion of their application server market share to JBoss in exchange for having applications locked into their underlying database systems.
What the author doesn’t know is that migrating from one database to another is a no brainer with Hibernate. You just tell it to use a different SQL dialect and the conversion is transparent.
He also seems to be rather disturbed at the idea that Hibernate is not standardized. Given that Hibernate is licensed under the LGPL, that doesn’t seem like too great a concern. The fact that EJB 3.0 is going to be focused on persistence of plain old Java objects rather than the cumbersome entity bean approach taken in EJB 2.0 is a win for developers, and the fact that Hibernate is the mechanism they’ve chosen is a win for me. Today is a good day for your humble author.
Hibernate versus JDO, or today is my lucky day
Sometimes you just have to look at the way things shake out and think, “I win.” This happens to me so very rarely that this feling is utterly alien to me, but I can now tell you that it feels pretty good. After years of writing my own code to copy values in Java objects to relational databases, I realized that I needed to take a good hard look at what was out on the market and see if I couldn’t simplify my life.
There were a lot of object-relational tools out there, everything from TopLink to Castor to EJB’s entity beans, to the standards-driven JDO. After a very unscientific survey of the market, I chose Hibernate. It seemed like a good choice to me because I could understand how it worked without reading a whole lot about it, because it didn’t require anything but including a few libraries with your application, and because it had good XDoclet support.
As it turns out, the people deciding how EJB 3.0 should work agreed with me. I read an EJB book last year and found persistence as defined in EJB 2.0 to be horrifyingly complex. Apparently, the EJB 3.0 expert group agrees with me, as they’ve chosen Hibernate 3.0 as the persistence implementation for EJB 3.0. For me, that’s great news. I already know Hibernate really well, and am quite fond of it, so this puts me ahead of the curve for once. Supporters of other options are not so pleased. The author of the column, a JDO proponent (I wanted to like JDO, I really did, but the timing wasn’t right or something), is quite bitter about the whole situation. Unfortunately, he’s ignorant when it comes to Hibernate:
What the author doesn’t know is that migrating from one database to another is a no brainer with Hibernate. You just tell it to use a different SQL dialect and the conversion is transparent.
He also seems to be rather disturbed at the idea that Hibernate is not standardized. Given that Hibernate is licensed under the LGPL, that doesn’t seem like too great a concern. The fact that EJB 3.0 is going to be focused on persistence of plain old Java objects rather than the cumbersome entity bean approach taken in EJB 2.0 is a win for developers, and the fact that Hibernate is the mechanism they’ve chosen is a win for me. Today is a good day for your humble author.
Commentary
Previous post
AfghanistanNext post
The seriousness of war