JPA – is it worth it? Horror stories with EclipseLink and Hibernate

One friend of mine brought Hibernate to our dev-team back in 2004 or so. But now he uses something much simpler and avoids ORM/JPA whenever possible. He can, because he is mostly master of his projects.

I had to get more familiar with JPA on my path. There is always more and more to learn about it. When you discover something like orphanRemoval = true on @OneToMany, it may bring you to the brink of crying. Because of happiness of course. (Stockholm Syndrome probably.) But then there are other days, when you just suffer. Days when you find bugs in JPA implementations – or something close to them. And you actually can’t choose from so many providers, can you? There are just two mainstream players.

Right now we are using EclipseLink and there are two bugs (or missing features or what) that kinda provoked our big effort to switch to Hibernate. What were our problems and what was the result of our switch? Read on…

EclipseLink and Java 8

You can avoid this problem, although you have to be extra careful. EclipseLink’s lazy list – called IndirectList – cannot be used with streams. Actually – if it didn’t compile, it would be good. Worse is it works but very badly.

Guys creating Java do their best to make streams work effortlessly, there are those default methods in interfaces, etc. But no, no luck here. IndirectList returns empty stream. Why? Because of this bug. (It works fine for IndirectSet.)

What is the cause of this problem? Well… someone decided to extend Vector, but instead of sticking with it, they also decided that the extended Vector will not be the actual backing collection, but they added their Vector delegate too. This works fine for interfaces like List, but not so for extended things. Now add “ingenious” design of Vector – full of protected fields you have to take care of… here IndirectList clearly collided with Vector badly.

Why do you need to take care of protected fields? Because creating the stream on Vector uses its special java.util.Vector.VectorSpliterator, that uses these protected values. So if you delegate to other Vector, you either delegate java.util.Vector#spliterator too (but then it won’t compile with earlier Java) or – preferably – don’t delegate to other vector and use that extended one as your backing collection. Of course, guys at Java might have used size() and get(int) instead of accessing Vector’s protected elementCount, elementData, etc. – but that would not be as efficient.

BTW: Anybody here likes Vector? I personally hate Java’s wannabe compatibility that really hurts its progress as we need to drag more and more burden with us.

JPA and counts on joins with distinct

The other trouble was related to a specific select where we used join with distinct instead of subquery with exists. We have an entity called Client that can be bound to any number of Domains, @ManyToMany mapping is used on Client side. Domain does not know about Client – hence the arrow.


We often need to obtain Clients where any of their domains is in a provided list (actual input parameter contains IDs of those domains). Using Querydsl, it looks like this:

QDomain cd = new QDomain("cd");
JPAQuery query = new JPAQuery(em).from(QClient.client)
    .join(, cd)

I’m sure you can easily transform it mentally to Criteria or JPQL – Querydsl produces JPQL, BTW. Distinct here has a special meaning that is used by JPA specification. Now you can call query.list(QClient.client) – it produces nice join and returns only distinct Clients. You try query.count(), and it works as expected as well.

But imagine that Client has composite primary key. We actually have exactly the same case, an entity bound again to domains, everything looks the same – just that entity has composite PK. List works alright, but if you try query.count() you’ll get completely different illogical query using exists and the join to Domains is lost completely. Results are wrong, definitely not the size of the list result.

There are some bugs filed for this – for instance this one. Because there was a discussion about this behavior we decided to find out how Hibernate treats this.


The trouble is that it is not the bug after all – at least not according to JPA 2.1specification which reads in section 4.8.5: The use of DISTINCT with COUNT is not supported for arguments of embeddable types or map entry types.

I found this today when I was gathering proofs for this post. Our story however would unfold in different direction. Are we using JPA? Yes. Are there other options? Yes!

Spoiler 2:

We used subselect with exists in the end, but that’s not the point. 😉

So we switch to Hibernate, right?

We got kinda carried away by some bug reports resolved as FIXED – like this one or the ones you can see in its links. But switching JPA provider isn’t that easy as promised. In the end we found out that count distinct for entities with composite PKs doesn’t work with SQL Server anyway. But we learned a lot of interesting things about how far both implementations are apart when it comes to translating JPQL to SQL. Mind you, I’m not actually sure whether everything we wrote in Querydsl (that generates JPQL) is 100% correct, but then it should say something. When it works I expect it to work after changing a JPA implementation.

Hibernate screwing deletes with “joins”

We have a lot of delete clauses that worked just fine in EclipseLink:

new JPADeleteClause(em, QGuiRolePermission.guiRolePermission)

This essentially means “delete all role permission assignments for role with specified description”. Piece-a-cake, right? We’re using implicit join there again, but it is the same story all over again – and it worked in EclipseLink just fine. EclipseLink creates proper SQL with exists:

  SELECT t1.gui_role_id FROM GUI_Roles t0, GUI_RolePermissions t1
    WHERE ((t0.description = ?) AND ( = t1.gui_role_id)) AND t1.gui_role_id = GUI_RolePermissions.gui_role_id
      AND t1.domain_id = GUI_RolePermissions.domain_id AND t1.permission_id = GUI_RolePermissions.permission_id)

It is not perfect – and we get back to it in section Random Query Generator – but it works. Let’s just compare it to Hibernate now. This is JPQL (actually this is the same for both providers as it’s produced by Querydsl):

delete from GuiRolePermission guiRolePermission
  where guiRolePermission.guiRole.description = ?1

This does not seem alarming – but the SQL is completely off:

delete from GUI_RolePermissions cross join GUI_Roles guirole1_ where description=?

This does not work on our currently used SQL Server, whatever dialect we choose. Why not go with exists? We have helper method that takes entity (Querydsl base path) and its where condition and performs delete. Now instead of:


We have to write this:

    new JPASubQuery().from(QGuiRolePermission.guiRolePermission)

Not terrible… but why? EDIT 2016-01-07: There is an issue filed for this, so far not fixed.

Another Hibernate’s twist

Things may get complicated when more relationships are involved. Take this simple JPQL for instance:

delete from Security security
  where security.issuer.priority = ?1

We want to remove all Securities with issuer (Client) having specific priority value:


There is another implicit join there, but one subquery with exists should cover it. Security class contains @ManyToMany relationships to Domain class through intermediate table Securities_Domains. That’s why we need two deletes here – and this is what EclipseLink generates (issuer is of class Client):

  SELECT FROM "Clients" t0, Securities t1
    WHERE ((t0."priority" = ?) AND (t0."id" = t1."issuer_id"))
      AND = Securities_Domains.security_id);
  SELECT FROM "Clients" t0, Securities t1
    WHERE ((t0."priority" = ?) AND (t0."id" = t1."issuer_id"))
      AND =;

It works just fine. But Hibernate shows its muscles really strong here!

delete from Securities_Domains where (security_id) in (
   select id from Securities where priority=?)

Obviously right the first delete is missing join to the Client entity in that subselect – and fails spectacularly. And we’re actually lucky we don’t have any other column called priority on Securities as well. 🙂 That could hide the error for ages.

With or without id?

Love that song… I mean the U2 one, not the Hibernate’s one. When you see JPQL with equality test on two entities you assume it is performed on their ids. So if you actually specify those ids, it should be still the same, right? Maybe it’s just some JPA myth after all. Consider this JPQL:

delete from MetaObjectSetup metaObjectSetup
  where not exists (select 1 from Permission permission
    where permission.metaObjectSetup = metaObjectSetup)

This produces query that does not work properly, probably taking last id from permission1_.

delete from META_Object_Setups where  not (exists (
  select 1 from Permissions permission1_
    where permission1_.meta_object_setup_id=id))

Version working with Hibernate must perform eq on id fields explicitly (EclipseLink doesn’t mind either):

   new JPASubQuery().from(QPermission.permission)

SQL result:

delete from META_Object_Setups where  not (exists (
  select 1 from Permissions permission1_

Experiences like these were the last drop for us and we reverted all the efforts to start using Hibernate.

Happy ending?

We switched back to EclipseLink after this. I don’t remember so much resistance from Hibernate like… ever. Maybe our JPQLs were too loose for it, joins were not explicit, aliases were missing, etc. But in the end it did not solve our problem.

It is really shame that count and distinct are not possible in the way making using query.list and query.count operations consistent in libraries like Querydsl. It is also shame that when it is not supported (as officially stated in the specification) it does not throw exception and does something fishy instead – silently.

You can do the same in SQL wrapping the select into another one with count – but JPQL does not support queries in the FROM clause. Pitty. However this is one of those cases when you can’t go wrong with correlated subquery. You just have to remember that subquery does not imply any equality implied by JPA joins (it can’t actually, there are cases when this would be an obstacle) and you have to do it yourselves – see the last examples from previous part (With Or Without Id).

This is all really crazy. Remotely, it reminds me horror stories about JSF and bugs of its various implementations (always different). Sure, things are really complicated, but then maybe the trouble is they are. Maybe it can be simpler. Maybe it’s wrong that I have to define @ManyToOne to be able to express joins. (Edit: Not true for JPA 2.1 as fixed in this post.) Any @XToOne has consequences often unseen even by experienced JPA users. Maybe some jOOQ or Querydsl over plain SQL is better than this stuff. I just don’t know…

Random Query Generator in EclipseLink

Let’s look at something else while we stick with JPA. Here we are back to Eclipse and there is one very easy thing I want to do in SQL:

  SELECT FROM Clients t0 WHERE ((t0.priority = ?) AND =

In plain wording – I want to remove all Client’s Contacts when this Client has some specific priority. If you ask for mapping… I hope there is nothing screwed here:

@Table(name = "Clients")
public class Client {
    @OneToMany(mappedBy = "client", cascade = CascadeType.ALL)
    private List<ClientContact> contacts;

@Table(name = "Contacts")
public class ClientContact {
    @Column(name = "client_id", insertable = false, updatable = false)
    private Integer clientId;

    @JoinColumn(name = "client_id")
    private Client client;

Back reference to client is mapped both ways, but one mapping is read-only. Both primary keys are simple Integers. No miracles here. And now three ways we tried, always with Querydsl, JPQL and SQL:

new JPADeleteClause(em, QClientContact.clientContact).where(
    new JPASubQuery().from(QClient.client)

// JPQL - logically exactly what we want
delete from ClientContact clientContact
  where exists (select client from Client client
    where client.priority = ?1 and client = clientContact.client)

// SQL contains double EXISTS and two unnecessary Clients more
    SELECT ? FROM Clients t2, Clients t1
      WHERE ((t2.priority = ?) AND ( = t0.client_id)))  AND =
bind => [1, 47]

Ok, it works, right? Can we help it when we mention id equality explicitly (…

new JPADeleteClause(em, QClientContact.clientContact).where(
    new JPASubQuery().from(QClient.client)

// JPQL looks promising again, I bet this must generate proper query - or at least the same
delete from ClientContact clientContact
  where exists (select client from Client client
    where client.priority = ?1 and =

// Three clients?!
    SELECT ? FROM Clients t3, Clients t2, Clients t1
      WHERE (((t2.priority = ?) AND ( = AND ( = t0.client_id)))
        AND =
bind => [1, 47]

You gotta be kidding me, right? What for?! I always believed that if id is entitie’s @Id, than it can do virtually the same with or without it. I even dreamt about using foreign key directly – but that’s way beyond capabilities of current JPA providers, so it seems.

Ok, let’s try something lame. Something I’d write only in JPA, not in real SQL, of course. Something with a lot of implicit identity equality hidden between the lines:

new JPADeleteClause(em, QClientContact.clientContact)

// not like SQL at all, but pretty logical if you know the mapping
delete from ClientContact clientContact
  where clientContact.client.priority = ?1

/* Surprise! Still one unnecessary Contacts in inner join that could go through FK,
 * but definitely the best result so far.
 * Mind though - this refused to work with Hibernate, at least with SQL Server dialect (any). */
  SELECT FROM Clients t0, Contacts t1
    WHERE ((t0.priority = ?) AND ( = t1.client_id)) AND =
bind => [47]

I hope this demonstrates the impotence of this field of human activity after more than a decade of effort. I’m not saying it all sucks – but after seeing this I’m not far from that.

With JPA doing too many things you don’t want or expect (unless you’re an expert) and many limitations compared to SQL I’d expect at least semi-good SQL. This is not close really.

Ramble On

So that’s another day with JPA. With proper query (or best approximation when it’s not critical) there is just one last thing we have to pay attention to… those IndirectLists that can’t be streamed. Just one last thing I said? Ouch… of course, we have to check our SQLs still and watch for any bugs or gray zones.

Yeah, we’re staying with JPA for a while on this project. But the next one I’ll start with metamodel directly over DB. I hope I can’t suffer more that way. 🙂 And maybe I’ll be able to do ad-hoc joins without @XToY annotations that always bring in stuff you don’t want. That’s actually one of my biggest gripes with JPA.

Many people avoid as much relation mappings as possible while they still can express their joins. Many people avoid @ManyToMany and map the association table explicitly, so they can reach all entities A for B’s id (or list of ids) – with a single join. Otherwise EclipseLink stubbornly joins all three tables as it’s understanding of PKs and FKs is obviously lacking.

Lessons learned? Not that much actually. But we’re definitely not switching provider for another couple of months at least!

24 thoughts on “JPA – is it worth it? Horror stories with EclipseLink and Hibernate

  1. But the next one I’ll start with metamodel directly over DB. I hope I can’t suffer more that way

    I think that this is the essence of the issues you’re experiencing. You’re mainly a DB-oriented person, and as such, thinking in SQL might appear more natural to you than thinking in terms of object-relational mapping.

    QueryDSL obviously cannot remedy any of this, it only provides type safe access to JPQL (more or less). I do think you’d be much more happy with SQL directly – or with jOOQ to add additional type safety and thus productivity to your developments.

    At the jOOQ team, we’re also “naive believers in a brighter future” 🙂 And that future definitely involves going back to SQL for what we call functional-relational transformation (or the end of ORMs)

    1. Hi Lukas. Querydsl is actually doing incredible job for those working with JPA, but it can go over SQL as well (never tried it so far). I don’t know exactly how these compare, although I noticed couple of discussions about it here and there. I don’t know whether I’m SQL oriented person, but I definitely found out that being SQL oblivious is just plain stupid. When I see seasoned developers struggle with JPA select for days just because they are not aware of LEFT JOIN… I don’t know what to say. So naturally one can only benefit from SQL – and then realize what JPQL does not support. 😉 I have more and more troubles to find the right fit for ORM, because you either just don’t care what is happening on SQL (wrong) or you feel that something not so smart is in your way (ORM) and you have to learn it to find out that there are things you can’t do anyway. No wonder people from non-EE world often mock us for adding the comlexity and then suffer from it. This is no essential but just accidental complexity.

      So while I’m no jOOQ user (yet), I think this is much better approach – whether with jOOQ or with Querydsl with SQLQuery. Or maybe we should use object DB or some noSQL… this is just schizophrenic.

      Thank you for reading and good luck with your project 🙂

      1. Or maybe we should use object DB or some noSQL…

        This is precisely where people will go into the next madness. I cannot stress this often enough, but for operations teams, moving away from well-understood RDBMS to some random niche database just because from a historic perspective, the OO and JavaEE folks didn’t really appreciate SQL’s relational nature is just going to cost more and more money…

  2. Wow! The first useful JPA comparison, not another silly benchmark! 🙂 I had a lot of pain with both libraries too, especially with propper SQL generation. Hibernate generated absolutely wrong SQL far away from the required in JPQL. Eclipselink has broken semantics for UPDATE/DELETE WHERE IN/EXISTS (while SELECT queries was OK). And the last thing I found is that EclipseLink has strange bug when working with @ElementCollection of @Embeddables. It occurs with disabled cache or sometimes eventually on intensive load-store operations ( I found the way to reproduce but there is still no response from EclipseLink team.

  3. I’ve been using DataNucleus JPA for several years. Does all I’ve needed to do, and has supported Java 8 since when it came out in March 2014 (which is fortunate since that is what I use and had issues with all others at that time). Maybe I’m not using something it doesn’t support yet, but it is definitely a quality JPA implementation worth a look. i.e there are more than just 2 to choose from.

    1. This wasn’t meant to be comparison or benchmark, but just exactly what the title says – horror stories. 🙂 I’ve been using JPA/ORM for probably 10 years by now, still learning new stuff. But the quality of query generation (or lack of thereof) stunned me, really. It is not easy to swap JPA providers either. There are implications, caching is solved differently, various extensions that just work without maybe even knowing about them, etc.

      My main trouble with JPA is that *ToOne annotation anyway – without bytecode automagic it can’t be made lazy – and that hurts. Now I’m going back in the JPA circle and using less annotations and it gave us huge performance gains. That said, we use JPA as a handy record over the table + entity manager with good JTA integration. We dumb down the rest, rely on SQLish approach – and help of convenient Querydsl. Apropos, Querydsl – their metamodel available through generated Qclasses is totally great when you have a rich filter framework, or just when you want to reference an attribute (not as a string that is).

      This is currently our middle-ground between too many surprises and throwing JPA out completely. I like it in this “mode”. 🙂

      1. Totally agree on QueryDSL, and the portability aspects. The absence of a public suite of compliance tests is frankly pathetic, and would go someway to alleviating the ability to swap around (or at least easily see what “features” are and aren’t supported on a particular implementation.

  4. Not sure if this is the case with EclipseLink but in hibernate *ToOne can be made lazy by specifying that its not optional. (i.e. it knows its there and therefore doesn’t have to load it due to presence of proxy implying not null)

  5. Ah yes the Object-Relational Impedance mismatch, always fun. I try to use Spring JDBC, after running into issues with Hibernate that were trivial in SQL, but impossible in Hibernate, as it does not fully support SQL-92, or even earlier versions too well. For simple stuff, Hibernate is great, and maybe if you can start from the ground up, but I’ve found Spring JDBC to take away the 80% boiler plate JDBC stuff very nicely, while still giving you the full power of SQL.

    1. Spring JDBC is my favourite alternative, I used its template successfully for going over a long cursor – something that may kill JPA with OOM error (although Hibernate offers some solution). What I don’t like on JDBC is it’s primitive result set mapping, I don’t know how much Spring makes this easier, but all those cumbersome conversions and guessing the right type on the input for updates… that’s simply too much when one wants to focus on the business. (For sure, ORM is also sometimes rather a distraction. :-))

  6. Seems like JPQL implementation between EclipseLink (which comes with WebSphere) vs Hibernate (which comes with JBoss) are different too.

    from User u where u.username = :username and not u.cancelled works on WebSphere but not on WildFly.

  7. I wonder why you are not using JPQL (Java Persistence Query Language). For me, I don’t do programmatic JPA queries, as they seem to be vendor-depending (how the vendor implements this). JPQL in contrast is vendor-independent (in your entity/logic/model code).

    @trajano Yes, sure they are. As long as you only imlement javax.persistence.* you *should* be okay, at least theoretical. 😉

    1. I was actually criticizing various bugs and/or wild differences in generated SQL, often bloated with unnecessary joins. All was based on JPQL (Querydsl generates JPQL), I checked that JPQL, and while I might have made some error, I’m absolutely sure about a couple of bugs in both EclipseLink and Hibernate, some of them quite critical, some reported years ago. The only way how to avoid them is to use the most rudimentary queries which makes JPA unusable (typically slow) for some scenarios.

      1. There is sure room left for improvements, like fine-granulated tuning and so. For example, orphan removal is maybe then not what you want there, when it left you crying about data loss. I had once forgotten (and now committed) to remove the DROP+CREATE strategy from my persistence.xml , you don’t want to hear THAT cries of forgetting also to make backups …

        But here, don’t blame the JPA! Blame yourself, the user of it. It just did what you told it to do. I for myself find the JPA (to make all persistence providers even at some point) very smart from Sun. In theory you can replace both JPA provider and your DBMS at the same time. And as long as you use javax.persistence.* you should be fine, not worrying about compatibility-issues. That was the main goal of the JPA, to have it possible to replace the persistence provider with almost zero changes to the code.

  8. Thanks! Excellent article and it is really good to know I am not alone with the JPA/Hibernate problem. I really don’t remember any real problem working with pure JDBC until this date. So yes, I completely agree with you.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s