Introduction to Java Persistence API (JPA)

The Java Persistence API, better known as JPA, provides POJO persistence model for Object Relational Mapping (ORM). It is basically a framework for managing relational data. You might be thinking over the relationship it has with Hibernate. Actually, Hibernate is one of the most popular framework that implements JPA.

Hibernate is a JPA provider.

The speciality of JPA is that it’s an independent API and can be easily integrated with any J2EE application.

JPA vs Hibernate

Re-iterating –

JPA is just the specification to access, persist and manage data between java objects and a relational database. JPA just provides the interface and the methods to achieve Object Relational Mapping (ORM). The actual implementation to JPA may be provided by Hibernate, Open JPA, Eclipse Link, etc.

This means that whenever the JPA contract changes, Hibernate and equivalent JPA providers must come up with their updates to incorporate the new implementation as per the changes in the JPA specification.

What is a POJO?

POJO is nothing but Plain Old Java Objects that do not extend or implement any other Java classes.

To quickly move on to the JPA demonstration, I would like to take the professor details from the user, thereafter remove a particular professor entry, later update the salary of a particular professor and finally print all the updated data available in the database table.

I start with creating a new Java Application and further creating a package com.jcombat.entity, which would be having the Professor entity class as:

Using the annotations, I specify the table name as jCombatProfessor and further map the properties to the corresponding table column names. You can make out that I have three columns in my table for ID, Name and Salary.

Note that we use @Id annotation to assign the primary key for an entity.

Let’s create the data access layer as com.jcombat.dao and create a class named ProfessorDAO, where we would be actually persisting an entity using the JPA. For me, it looks like:

Note that in the ProfessorDAO constructor, I have created the instances for EntityManagerFactory and the EntityManager, to make sure they get instantiated whenever a new ProfessorDAO object is created. This varies in a Spring application, where the EntityManagerFactory must be instantiated when the Spring container initializes itself through applicationContext.

createEntityManagerFactory of the bootstrap class Persistence, accepts the Persistence Unit Name as the parameter. So, the next question is, from where does it take the Persistence Unit Name?

Yes, we need to create a persistence.xml file inside the META-INF directory of the project.

When using JPA in a standalone java application, we must specify a persistence provider somewhere. So it needs to be specified inside persistence.xml under the <provider> tags. But once we do that, we must make sure that the appropriate provider JAR file is added to the build path. For Hibernate as the provider, make sure the hibernate-entitymanager.jar file is added to the build path of the application.


Location: src/META-INF

Not all of the properties above are mandatory. The Persistence Unit Name that we assign in the above persistence.xml should be the same as the one we provide while creating the EntityManagerFactory. More than one persistence unit definitions can be present in a persistence.xml file. To instantiate the EntityManagerFactory, we need at least one persistence unit.

I now, go for creating the service layer as com.jcombat.service and create a service class ProfessorService as:

Time to create my presentation  layer. Create a package named as the presentation layer.

Then, I create a class ProfessorMain as:

We have provided easy choice selection using the Switch statement, so the user can easily switch over to whatever he wants to do. Now all you need to run the application.

EntityManagerFactory vs SessionFactory

Though SessionFactory and Session can be used instead of EntityManagerFactory and bwith Hibernate, it’s not a good option though. The reason being the same as why we prefer using List as the reference type and not ArrayList while initializing an ArrayList. So tomorrow there might be a requirement asking to switch over to a different JPA provider. Had we used SessionFactory and Session, which is Hibernate specific, there might arise a havoc where it’s possible that the new provider implementation never uses a Session to manage objects. So in that case, we would need to manually fix every occurrence in the application, which could get as tedious as hell. However, if we would have used EntityManagerFactory and EntityManager, which is the JPA standard specification, we wouldn’t have to worry about the implementation any JPA provider provides. The EntityManager manages the set of entities internally by calling the respective provider-specific implementation. This means that if we have Hibernate configured as the JPA provider, the EntityManager invokes the hibernate Session under the hood.

persistence.xml vs hibernate.cfg.xml

We might have come across places where we use persistence.xml, while at some other places we use hibernate.cfg.xml or hibernateContext.xml. So the question is, where do we use what? Below is what you need to know –

If we are using Hibernate’s proprietary API, we will need the hibernate.cfg.xml. But if we are using JPA, we need to explicitly specify the provider whose EntityManager implementation will be used by JPA. In this case, we need to specify the provider in persistence.xml. We generally don’t need to use both. hibernate.cfg.xml is for Hibernate, while persistence.xml is for JPA.

Few points to note in this demo are that –

  1. We haven’t handled the exceptions gracefully.
  2. This is the most basic example for JPA we could think of as the primary purpose of this article was to understand the concept of JPA and JPA providers.

Receive our updates to your inbox

Get more stuff like this
in your inbox

Subscribe to our mailing list and get interesting stuff and updates to your email inbox.