To Jalapeño or to Hibernate the data...

Comparison between Jalapeño and Hibernate

SQL

In both systems, you can still use SQL on the underlying database. Thus, you can apply your own queries to the underlying data model and treat it as a set of relational tables.

Mappings

One key differentiator between the two is the lack of any mapping files in Jalapeño. This contrasts with Hibernate where the XML mapping files are the underlying mechanism for providing the object to relational mappings. However, although the default mapping provided by Jalapeño needs no additional annotations, if you wish to apply different mappings to your objects you end up needing to capture the same sort of meta-data as Hibernate, just in a different format.

Refactoring

One very nice feature of Jalapeño is that you are able to modify your Java objects during development. Then at an appropriate point, you are able to re-generate the Caché classes from these modified classes. The underlying data model is updated and you are able to work with the new model. This makes the integration between the object world and the relational world very agile.

Database independence

An important point to consider is that Jalapeño is very closely tied to Caché and does not work with other relational databases - whereas Hibernate can be used with any relational database. Thus, Hibernate does not tie you into a particular vendor's solution and, if it turns out that you need to migrate to a new database for any reason, your Hibernate system can go with you. This is not the case with Jalapeño.

Caché database structure

Following on from the previous sections' theme, as Jalapeño is tied to the Caché database, it is worth noting that the Caché database is not primarily intended as an implementation of the relational model [although it has been re-written not so long ago to offer native relational support – Ed]. While in many situations this may not be a significant factor (as we are primarily concerned with persisting objects into the database), there may be some exceptions. For example, should you need to access the same information from other systems then the resulting solution may or may not offer the flexibility or performance required. This may therefore be a factor in your selection (or not) between O-R mapping tools and object database systems.

You have to pay for Caché/Jalapeño

Another criterion that can be relevant to many organisations is that Jalapeño and Caché are commercial products. This may be viewed as both a negative and a positive thing. It may be viewed as a negative in that you must pay for commercial software, where as tools such as Hibernate are free. The positive may be that as you pay for the product, you may have a right to expect, and may receive, a high level of support. Indeed, in at least one industry I have worked in the lack of a commercial support contract would mean that open source software would not be considered a viable option.

Adoption

Hibernate is extremely widely adopted. This means that not only has it been validated on many applications worldwide, but there is a large developer pool out that that you can drawn on if necessary. Whereas, as far as I know, the Caché market is much smaller. That is not to say that because of this it is any less effective than Hibernate. However, should you need to recruit developers with Caché knowledge, you may find they are either not available in your area or available only at a premium.

Conclusions

The bottom line here is: "Would I use Caché and Jalapeño on my next development project given the choice?" Personally, I think I would start from the vantage point that I have Hibernate available as a well-tried and trusted O-R mapping tool – so, what is it that Jalapeño gives me that Hibernate does not?

The short answer is, it avoids the need to create XML based mappings of my objects. However, personally, I am not convinced that I might not end up creating the same amount of meta-data in terms of annotations, but now defined with my POJOs. In addition, I would want to benchmark Caché as a database system against my preferred relational database to ensure that it provided the performance and scalability required [Cache, of course, would claim that it outperforms a pure RDBMS in both areas; but any such claims must, as John says, be verified in your environment with your data - Ed]. ®