Use of Hibernate With Java Persistence Api

Before we start any discussion about Persistence technologies, we need to understand what exactly Persistence is in computer science. Persistence, in simple terms is the ability to retain data structures between various program executions. A perfect example of this would be a word processor saving undo history. In practice, this is achieved by storing the data in non- volatile storage such as a file system or a relational database or an object database.

The popularity of databases has increased manifold in the past few years. Java has become the preferred choice of developers for developing secure, flexible, and scalable database driven web applications. These web applications require objects to be associated with appropriate databases. Hibernate, along with other persistence technologies associate’s objects with the appropriate database in a simple, straight forward and natural way.

Hibernate is one such effort from the Java community to develop many object oriented solutions to data persistence. Any kind of Java persistence solution includes two main elements i.e. ORM (Object Relational Mapping) and OOM (Object Oriented Modeling).

Hibernate has become immensely popular amongst the developer community as it is a free, powerful, high performance open source object – relational mapping persistence Java package that makes it easier to work with relational databases for Java Applications.

Apart from Hibernate, other popular open source Java persistence technologies include JDBC, abates, JDO, Top Link and CMP Entity Beans. These technologies provide a standardized object-relational mapping mechanism.

Java persistence application programming Interface or JAVA Persistence API is the latest version of the Java Data Objects (JDO) technology which was the earlier persistent technology used by developers. JPA or the Java Persistence API is the latest Java Specification standard for java enterprise applications. The Java Persistence API is a java programming language framework that allows developers to manage relational data in Java standard edition and Enterprise Edition applications. Java Persistence API originated as part of the work of the JSR 220 expert group.

The java persistence API’s has been developed after drawing upon the best ideas from other prevalent persistence technologies like Top link, JDO, Hibernate etc. In simple words, Java Persistence API is a Plain Old Java Object API for object /relational mapping and supports a rich, SQL –like query language for both static and dynamic queries.Vendors involved in application development have found that the use of Hibernate technology with Java persistence API’s helps build flexible, database driven web applications that are highly scalable and involve complex business processes.

The Java Persistence API is the standard object/relational mapping and persistence management interface of the Java EE 5.0 platform and Java Web Services Development . As part of the EJB 3.0 specification effort, it is supported by all major vendors of the Java industry for improving Java Web Development in India and Globe.

More Java Articles

Techniques For Integrating Hibernate Into Legacy Java Code – Part 1

If you’re like me, you spend a lot of time dealing with legacy code that, for whatever reason, does not take advantage of modern methodologies and libraries. I’ve taken over Java projects that contain hundreds of thousands of lines of code and not a single third-party jar other than a JDBC driver! One of the most common examples of this is the implementation of the data access layer. These days, the de facto methodology involves Hibernate and DAOs, usually managed by Spring.

This article will detail the steps I recently took to covert a large application from custom-written data access to Hibernate and Spring using the refactoring facilities in Eclipse. The key with this refactorization is to get the existing business logic code (Struts Actions, JSPs, Delegate classes, Business Service classes, etc.) to access the datastore using Hibernate, managed by Spring, without manually changing any of that code directly. Part 1 will include creating the Hibernate data object classes, DAOs, and refactoring the existing code to work with these newly created types. Part 2 will conclude the project with integration of the Hibernate DAOs and wiring everything up with Spring.

First of all, we need to create our Hibernate model and DAO classes. Obviously, since we’re dealing with a legacy application and data structure, we will want to use a bottom-up approach to building our data access layer. This just means that we’re going to generate the Java code and appropriate Hibernate config files from the existing database. There are many tools freely available to make this process very painless. I recommend an Eclipse Plugin for creating and maintaining the Hibernate artifacts (Google “Hibernate Eclipse Plugin” to get started). The structure and requirements for creating Hibernate classes and config files are well documented elsewhere, so I won’t go into detail here. However, in this particular project, the Hibernate DAO lifecycles are managed by Spring, so the DAO classes should all extend HibernateDAOSupport.

Now we have java classes (POJOs) which map to our database tables, but none of the existing code uses these new data object classes. This is where the refactoring tools of Eclipse comes in really handy. For example, say we have a legacy class called AccountInfo which corresponds to the ACCOUNT database table. Right-click the class and select Refactor -> Extract Interface. On the dialogue box, call the new interface IAccount and make sure you select “Use the extracted interface type where possible.” Choose the other options according to your preferences. Click OK and kick back while Eclipse changes every occurence of AccountInfo references to IAccount references and recompiles. Of course, do this with each object model class.

If you never realized why OOP languages are so great, you’re about to. Now we’re going to refactor the code so that all of the existing legacy can be hooked into the new Hibernate model classes instead of the legacy ones. Continuing with the AccountInfo example, create a new class – you’ll probably want to create a new package for this step – called Account that extends the Hibernate POJO for Account and implements the new IAccount interface.

This next part is the most time-consuming, but really isn’t that bad. At this point, the newly created class will probably contain a bunch of empty methods containing only TODO comments. This is because the IAccount interface most likely defies a bunch of methods that are not implemented in the Hibernate Account POJO. To deal with these, we basically want the new Account class to delegate to its generated superclass whenever necessary to satisfy its contract as an IAccount type. As a real world example from the application I was working on, the legacy AccountInfo class defined a getter/setter pair for a property called username, whereas the corresponding column in the ACCOUNT table was actually LOGIN_NAME. To deal with this, you would simply implement the get/setUsername methods in Account to delegate to get/setLoginName (from its superclass). I also had to translate between various data types quite a bit. For example, the legacy code would define many properties as Strings even though the corresponding piece of data in the database was defined as an INT or TIMESTAMP. Again, do this with each object model class.

To finish up the data model layer, edit the appropriate Hibernate and Spring configuration files to refer to these new object model classes. The application now has the ability to map database records to Java objects via Hibernate, and the legacy code which refers to these classes has not required any editing by hand. To finish up this refactorization project, we need to hook in the Spring-supported Hibernate DAOs in a similar way. In Part 2 of this article, I will discuss refactoring the legacy code to read, write, and update data using Hibernate and Spring.