Over a million developers have joined DZone.

The problem with JPA/Hibernate (or the future of ORM)

DZone's Guide to

The problem with JPA/Hibernate (or the future of ORM)

· Java Zone ·
Free Resource

Delivering modern software? Atomist automates your software delivery experience.

I know, a lot of people are happy to work with JPA and Hibernate. Consider this a post from somebody who thinks things can be improved.

I have a love/hate relationship with Hibernate, for many reasons that I don't want to go into now. Overall I do like Hibernate and think it does a good job but it can be improved in many ways.

I also believe it was a mistake to base the JEE 5 specifications on Hibernate. An object-relational mapping tool has to bridge the gap between ... classes, objects and tables, records. For me Hibernate is a step in the right direction but it's far from perfect. I would have preferred to not have a persistence specification at all in JEE because we're not there yet, but we're doing well.

Object-relational mapping tools have a hard time and not only from all the flack they get. Have you ever looked at how classes and tables are almost each other's opposites? And have you ever wondered how that impacts classes that are mapped with Hibernate?

In database tables - in general - when you follow relationships (foreign keys) you go from general to specific. For example, you follow the foreign key in the ADDRESSES table to the PEOPLE table. But why link an address to a person when other things can have addresses as well? Buildings, companies, customers, hotels, ... .

Maybe you don't have any of these other things in your database, you only have PEOPLE. Ok, then consider what your Address class looks like:

public class Address {
private Person person;
// rest ommitted

Maybe you're not worried about this, but why does the Address class have a dependency on the Person class? In a pure object-oriented world that relationship would be determined by a List in the Person class.

public class Person {
private List<Address> addresses = new java.util.ArrayList<Address>();
public void addAddress(Address address) {

I hear you, the world isn't perfect. But ... there is an Java object-oriented framework that would let you save these kind of objects in a relational database. And you don't have to specify any mapping configuration.

It's called BeanKeeper (here's an introduction article).

First of all, BeanKeeper as it is today can't replace Hibernate or JPA. Since you don't provide a mapping configuration BeanKeeper decides by itself which tables to create for each class. You don't have any control over the relational part. And you can save any object you like, BeanKeeper does the hard work.

Still, for me it's proof that things can be different in object-relational mapping. I believe well-designed object-oriented frameworks start with a set of sound and consistent principles of how classes and tables should or could be mapped. Object-oriented framework don't have to solve every possible problem. And they don't have to support every possible mapping.

By taking a stance that some mapping constructs are not supported it would actually be possible to have better frameworks. Or at least, it would be possible to have a better experience.

A better alternative to Hibernate or JPA would in my opinion have to copy some BeanKeeper ideas. It should be possible to map a one-to-many relationship to a Person class with a List of Addresses. And there will have to be some form of mapping configuration.

Hibernate and JPA are a evolutionary step in the right direction, but they are far from perfect. I hope that some people are working today on better alternatives. If you do please post a comment below.

If you have your own opinion on the future of object-relational mapping let us know!

Start automating your delivery right there on your own laptop, today! Get the open source Atomist Software Delivery Machine.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}