Using ObjectDB in Java Projects

ObjectDB is entirely written in Java with an object database model as its underlying principle. The database can be used in two different modes—client-server mode or as an embedded database object in line with the application process. The intriguing aspect of this database is that, unlike other object databases, ObjectDB completely adheres to JPA, the JDO standard of Java APIs. Due to this built-in facility, ObjectDB neither has any specific APIs of its own nor does it require any intermediate ORM support to facilitate database transactions. This article provides some key concepts to work with ObjectDB in a Java application.

An Overview of Data Persistence in Java

Java objects are instances of user-defined classes that represent real world data. They are often stored in databases or file systems in the course of an application life cycle. There are mainly four ways to achieve persistence in Java—serialization, JDBC, JDO, EJB, and JPA. The implementation technique varies wwhen using each of these principles.

• Serialization helps in a relationship store among a graph of Java objects, but it does not support sharing among multiple users.
• JDBC, on the other hand, requires explicit management of values of fields and to define how to map them into relational database tables.
• Enterprise JavaBeans, on the other hand, requires a Java EE container to run.
• Java Persistence API (JPA) is quite flexible and can run either in a container or in a JVM.

Moreover, when we work in a small footprint environment we need to manage data in a local repository. So, our obvious choice would be JPA, JDO, or JDBC.

JDBC provides a set of low-level APIs to interact with the database. These APIs wrap storage/retrieval procedures within a stream of SQL queries. Java, being an object-oriented, language is quite naive of the SQL structure (and the 2D array storage structure of a relational database) which most relational databases quite stubbornly adhere to for any sort of interaction. Java, at best, can bring a third-party framework such as ORM, which acts a bridge in mapping Java objects into a relational store via SQL and vice versa. ORM made developers more productive; they now can create Java classes that implement business logic, rather than involve the intricacies of mapping them to the data source. The ORM solution, however, has been around for a long time, even before Java. ORM solutions were used successfully in languages like Smalltalk but were never really standardized.

Java standardized persistence API with Java Data Object (JDO) defines classes and interfaces to be used by the programmer to specify the contract between suppliers of persistence classes and the run-time environment. And, the vendors who implement them are called JDO vendors. Later, as a part of the EJB3 specification, Java supplied another standardized persistence APIs called Java Persistence Annotation (JPA). JPA provides a set of annotations and interfaces similar to the goals of JDO, facilitating inter-operation of applications in both JPA and JDO. So, in most cases when we talk about JPA we also talk of JDO. JPA is primarily good for working with persistence in relational data stores. However, Relational data stores are not the whole world. There are other data stores built upon various data models such as object data model. In such a situation, we should consider JDO as a specification standard.

ObjectDB Overview

ObjectDB be an object database model, created completely in Java; rightly included is the JDO, JPA standard. This brought forth a manifold advantage; a few of them are as follows:

• Because ObjectDB is completely written in Java, they share an invisible camaraderie as they go along together pretty well. Embedding it in a Java application is as simple as including only one jar archive file, named objectdb.jar; that’s all. You need no JDBC driver and nothing else. ObjectDB database comes in a zipped archive [download]. Once unzipped, the bin folder contains the required jar, objectdb.jar, and can be included in any Java project as an embedded database.
• ObjectDB is completely JDO, JPA compliant. That means the required dependencies for object persistence are already there without requiring the programmer to explicitly include them in the Java project. This adherence to the Java Persistence standard is particularly useful under heterogeneous database portability, provided they support the same JDO, JPA standard.
• As with database portability, ObjectDB has no issues regarding platform portability. It can deliver equally well or at least as expected, in any OS platform. An embedded database has no such issue. This, however, is to be looked for while working with the client-server mode of ObjectDB.
• As should be obvious, ObjectDB is friendly to any type of Java Application, be it standalone or enterprise. The integration into Java EE or Spring Web applications is quite simple. Popular Servlet containers such as Tomcat, Jetty, and also the application servers such as GlassFish, WildFy, and so forth, plays pretty well with ObjectDB.
• Now, this all seem hunky-dory. Performance can mar the luster of every features described above. A little of my experience with this database exulted me write this article. Performance is excellent vis-a-vis other databases (most of them were relational, in my case). Have a look; I found this comparison quite interesting.

A Quick Example

Although implementation is pretty straightforward, for the sake of completeness, let’s implement a simple example.

Entity Class

package javaobjectdbapp;

import java.io.Serializable;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class AddressBook implements Serializable {
   private static final long serialVersionUID = 1L;
   @Id
   @GeneratedValue
   private long id;
   private String name;
   private String address;

   public Address() { }
   public Address(String n, String a) {
      this.name = n;
      this.address = a;
   }
   public Long getId() { return id; }
   public Long setId(Long id) { this.id = id; }
   public int getName() { return name; }
   public Long setName(String n) { this.name = n;}
   public int getAddress() {return address;}
   public Long setAddress(String a) {this.address = a; }
   @Override
   public String toString() {
      return String.format("(%s, %s)",
         this.name, this.address);
   }
}

CRUD Class

package javaobjectdbapp;

import java.util.List;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
import javax.persistence.Query;
import javax.persistence.TypedQuery;

public class JavaObjectDBApp {
   public static void main(String[] args) {
      EntityManagerFactory emf
      = Persistence.createEntityManagerFactory(
         "$objectdb/db/address-book.odb");
      EntityManager em = emf.createEntityManager();
      em.getTransaction().begin();
      AddressBook b1=new AddressBook("Mickey Mouse",
         "Disney");
      AddressBook b2=new AddressBook("Donald Duck",
         "Disney");
      AddressBook b3=new AddressBook("Hulk",
         "Marvel");
      AddressBook b4=new AddressBook("Spiderman",
         "Marvel");
      AddressBook b5=new AddressBook("Superman",
         "DC");
      em.persist(b1);
      em.persist(b2);
      em.persist(b3);
      em.persist(b4);
      em.persist(b5);
      em.getTransaction().commit();
      TypedQuery<AddressBook> query
      = em.createQuery("SELECT b FROM AddressBook b",
         AddressBook.class);
      List<AddressBook> results = query.getResultList();
      for (AddressBook bb : results) {
         System.out.println(bb);
      }
      em.close();
      emf.close();
   }
}

Conclusion

Perhaps, working with ObjectDB is simpler than any of the available database in the market. The bonding between Java and ObjectDB is obvious. The article has not dealt with the tool that comes with ObjectDB. These tools provide an interface to maintain a database locally. So, in a way, the database package is complete for programmers to get their hands dirty.