Endorsing the Candidates
Today, residents of Iowa will participate in the state's causas, the first in this election. They will cast their vote for the Democratic party's presidential nominee. The Iowa caucus draws a lot of national attention because it is the first test for the candidates, and establishes the elections early leaders...and losers. After the votes are tallied, we'll see the field of prospects, currently at eight, thinned as the candidate (or candidates) who trails in votes will concede defeat and likely give his endorsement to one of the stronger candidates who remain. The party's resources are then more focused.
About a year ago, I considered candidates for an Java-based Object/Relational mapping tool. I had been spoiled after working with Apple's Enterprise Objects Framework (EOF), part of WebObjects, but I needed something that I could use in a J2EE and WebLogic environment. Fortunately, the field of candidates was large. I held a caucus, of sorts, where I established my platform and the "issues" the candidates would need to address. The ideal candidate would be open source, so the project need not be delayed while I sought approval for a procurement. Candidates which require byte-code manipulation, or inheritence of a particular base class, or implementation of a specific interface, were struck from the ballot. So were those that appeared to have abandoned their campaigns; the nominee must be actively developed and supported.
These criteria narrowed the field to two candidates: Hibernate and ObJectRelationalBridge (OJB). Eventually, I settled OJB because it best supported an object-oriented approach to creating queries. Hibernate, on the other hand, uses a proprietary languaged called Hibernate Query Language (HQL). One of my goals was to rid my Java code of the embedded SQL and associated string manipulation. Hibernate merely substituted another language, HQL, for SQL, but the string manipulation remains.
While I've been happy with OJB, and have since used it on additional projects as well as recommended it to colleagues for use on their own projects, OJB is not without its quirks. First, it remains in a "release candidate" state (though I would recommend it even for production applications). A more focused campaign, which abandoned support for the ODMG and JDO APIs, would have likely helped it reach release status much sooner. After all, one reason to use an O/R mapping tool like OJB is to avoid the complexities of JDO. Most noticible, though, is that it's documentation is a bit sparse (though it has admittedly, improved since I first used OJB).
I've now learned, from comments on this ONJava.com article, that Hibernate 2.1 supports query-by-criteria, similar to both OJB and EOF. And Hibernate's documentation is much more complete and readable than that of OJB. Hibernate claims to be the most popular Object/Relational Mapping solution for Java, and I'm sure that their impressive documentation is largely to thank for that. So I've decided to give it a second look at this candidate.
Nothing attracts a crowd like a crowd, so Hibernate's popularity is likely to grow. If Hibernate is the People's Choice, is OJB an Also Ran? Let's expand this issue beyond Hibernate, OJB, and other object-relational mapping tools, to the open source software market as a whole. When one project becomes the dominant or popular solution, would developers be better served by divided development efforts and the variety this affords, or by a focussed and collective development effort?
Stated another way, should OJB abandon its campaign and lend its endorsement (and resources) to Hibernate? I'm still an undecided voter; I'm far from abandoning OJB in favor of Hibernate. But it does look like Hibernate has some advantages over OJB. Likewise, OJB has features to offer that Hibernate may not. But what if developers of OJB were to endorse Hibernate, the apparent popular choice, and help that team create a product that is the best of both worlds?