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

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.