Java is an excellent Object Oriented language that allows developers to write sophisticated, powerful, enterprise scale applications. Such applications typically involve a large amount of data that must be stored somewhere for future use.

That is, the data in the objects within the JVM must be persisted using some form of permanent storage. Typically, this involves storing the data within some type of database. In general, this means relational databases such as Oracle, DB2, MySQL or Postgres etc.

Whenever data is stored within a relational database, using the relational model, there is a necessary mapping required between the relational world and the object-oriented world. This mapping is rarely trivial and can be a complex aspect of an application in its own right. Object-Relational mapping (also called OR mapping or ORM) has become a subject area in its own right, with numerous articles and books dedicated to it.

In addition, tools have emerged, both commercial and as open source, to help with this difficult task. Within the Java world, examples can be found in the JDO and EJB3 specifications. JDO (or Java Data Objects) is a standard, and several implementations are available from different vendors. EJB3 (the Enterprise Java Beans 3 specification) is another option. However, there has been confusion of the two approaches and their relationship, which is only now being resolved. This is being achieved by yet another new standard, which aims to bring the two existing standards together.

However, within the Java world, the clear market leader is the Open Source Hibernate system now supported by the JBoss organisation (and which is distributed under the GNU Lesser General Public License). Its aim is to remove most of the drudgery and time consuming repetitive coding required to implement your own Java-to-Relational mapping system

A commercial offer also aiming to simplify the task of persisting object data is the Caché system from Intersystems. Caché is described as a "post-relational database" system by Intersystems. By "post-relational", it means a database system that integrates three data access options that can be used simultaneously on the same data. The three options allow the data to be viewed as an object database, accessed via an SQL relational view, or viewed via a rich multidimensional access facility. Note that this means that plain SQL can be used to access an object database – although Intersystems are not the first to offer this facility; it is still not widely available.

In this column we will look at Intersystems' Jalapeño data persistence technology; compare it with features from Hibernate; and contrast the two approaches.

Jalapeño

The introduction of the Jalapeño technology is a key feature of the latest version of Caché. Jalapeño (which apparently stands for JAva LAnguage PErsistence with NO mapping) allows Java developers to create Plain Old Java Objects (POJOs) and then to persistent them directly in the Caché object database. This can be done without the need to create tedious (and potentially difficult to maintain) object-relational mapping, and without needing to learn or use special Caché tools or scripts.

The key here is that Java objects are persisted as first class objects within the database system. This aims at eliminating the need for object-relational mapping within developers' own code or configuration files. This should reduce development time and improve the maintainability of the system. It is also claimed that this will provide a performance benefit as well.

Working with Jalapeño

If you wish to use Jalapeño within your application, apart from obtaining the Caché database, there are two things you will need to do. These are to create the Caché classes which bridge the gap between the POJO classes a developer writes and the Caché database. The second is to include and use the Jalapeño Object Manager within their Java application.

To create the Caché classes, a utility class called the Schema Builder is used. This class takes the POJO classes and generates Caché classes for those POJOs. If required, a developer can control the results of this process by using Java SE 5 annotations within their class definitions. These annotations are optional, but they allow for a more sophisticated Java object to Caché object mapping to be performed. For example, they can be used to support many to one mappings etc.

An example of what such a POJO might look like is presented below.

import com.intersys.pojo.annotations.CacheClass;
import com.intersys.pojo.annotations.Index;

@CacheClass(name="Employee",primaryKey="ID",sqlTableName="EMPLOYEES")
@Index(description="Name Index on Employees  table",name="EmployeeIndexOne", 
propertyNames={"name"},sqlName="EmployeeIDX")
public class Employee {
public String name;
public String employeeNumber;
public String extension;
}

From this is generated a Caché class using the Schema Builder. If their Employee class changes in any way, all that is required is that the Schema Builder is re-run. The result is that those changes will be reflected in the corresponding persistent Caché classes. From this, it can be seen that no changes are made to the actual POJO – other than the above annotations, there is nothing to tell you that the data in this object is persistent. Indeed, it is possible to use features plugged into an IDE to run the schema builder and update the Caché classes.

The final piece to this puzzle is how the data in the POJOs gets into the database and how previously persisted objects are resurrected. The answer is through the Object Manager. This class is used to store and restore persistent objects in the Caché database.

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]. ®

Related stories

• JBoss mines richer Seam for Web 2.0 goodness (13 December 2006)

  https://www.theregister.com/2006/12/13/jboss_seam/

• Beginning Hibernate (28 November 2006)

  https://www.theregister.com/2006/11/28/beginning_hibernate/

• The database abstraction framework strikes back (22 November 2006)

  https://www.theregister.com/2006/11/22/cplusplus_database_framework/

• C++ Generic Coding vs. Java Frameworks (9 October 2006)

  https://www.theregister.com/2006/10/09/c_plusplus_frameworks/

• Red Hat wraps up JBoss combo to go (18 September 2006)

  https://www.theregister.com/2006/09/18/jboss_joins_red_hat_applications_stack/

• Object databases - alive and kicking? (17 May 2006)

  https://www.theregister.com/2006/05/17/object_database_interest/

• A nice case of Mumps? (23 December 2005)

  https://www.theregister.com/2005/12/23/mumps_m_prgramming/

• Hibernate Object Relational Mapping (Part 2) (6 December 2005)

  https://www.theregister.com/2005/12/06/hibernate_object_relational_mapping_2/

• Hibernate Object Relational Mapping (3 December 2005)

  https://www.theregister.com/2005/12/03/hibernate_object_relational_mapping/