JPA without Spring (or any DI framework)

JPA is the ORM defined by the Java Community Process, that is to say, it is a JSR (317). Previously to JPA, there were a couple of ORM occupying the scene, like Hibernate or iBatis. So the community realized Java needed it's own ORM.

As any other JSR, the specification is defined through some documents, some interfaces and abstract classes, a couple of tests, etc., and let the vendors to implements the details. There are three main JPA implementations: Hibernate, EclipseLink and OpenJPA. 

The idea, as always, is to program using the specification (classes,interfaces, annotations, etc) and make the implementation available in the classpath so the details are resolved at runtime. That gives you the freedom to choose the implementation that fits better for your project or to change it without touching your source code.

I've been working with JPA for a couple of years in different projects, and most of the time it's configured through a dependency injection (DI) framework like Spring, where the EntityManager is injected in some DAO class.

Although using a DI framework may be the most appropriate approach for plumbing JPA in an enterprise scenario, it is very interesting to dig a bit and see what happens in the underground. This helps a lot to understand what is part of the specification and what is part of the salad of framework you are using.

Obtaining an EntityManager

The process for obtaining a working EntityManager, follows the same approach as others JSR (check my post about Bean Validation) for obtaining the specification hero, in this case, the EntityManager.
Basically, there is a class that searches in the classpath for a factory implementation that can build the EntityManager:

EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPAEXAMPLE");

EntityManager  entityManager = emf.createEntityManager();

The method createEntityManagerFactory() in Persistence class, takes as argument the persistent unit name (defined in persistence.xml file), and searches in the classpath for a JPA implementation (and also of course, for the persistence.xml file). With the EntityManagerFactory in place, an EntityManager can be built.
Once the EntityManager is created, it is ready for being used:

Person person = new Person();
person.setAge(30);
person.setId(1L);
person.setName("John Doe");


entityManager.persist(person);

Simple as that. All the time, the specification has been followed an no vendor specific code was used.

Conclusion

As you can see, getting JPA running is very simple. Though the most appropriate approach is to use a DI framework, it is always interesting to understand how things works and distinguish what is what. 
Using the specification for obtaining an EntityManager is very helpful for playing around with JPA when you are starting with the ORM.

The example code

I leave you an example project that uses Hibernate as the JPA implementation. It is configured with Maven. 


Download example


You can try changing the JPA implementation from Hibernate to EclipseLink. Three steps are required:

1. Rename persistence-eclipselink.xml to persistence.xml.
2. Check the pom.xml file, in order to change Hibernate dependencies for EclipseLink dependencies, and build.
3. Check that no source code had to be updated :)