38

I was wondering if anyone has experience with the JPA2.0 implementation of any of those frameworks? Especially together with Spring3.x which comes with EclipseLink support.

Do you use any of those frameworks and JPA2.0 for production? Any severe issues?

Ta Sas
  • 9,573
  • 15
  • 51
  • 73

4 Answers4

36

EclipseLink is more standards compliant, since it is the reference implementation for JPA 2, Hibernate has some compliancy issues, but is more mature.

One of the main benefits of EclipseLink is that you can call native SQL functions directly in your JPQL queries. In Hibernate this is not directly possible.

But Hibernate has a bigger community, better documentation and also better error messages.

Timo Westkämper
  • 21,824
  • 5
  • 78
  • 111
  • 1
    I disagree. Being the RI doesn't make you more compliant and I've faced issue with both implementations although they are supposed to be JPA 2.0 compliant, see [this question for example](http://stackoverflow.com/questions/3014313/jpa-2-criteria-api-why-is-isnull-being-ignored-when-in-conjunction-with-equal). The TCK is just not exhaustive. – Pascal Thivent Jul 13 '10 at 07:19
  • @pascal-thivent, EclipseLink's JPQL implementation is in fact more standards compliant then Hibernate's. And being the RI puts you into some kind of reference position. – Timo Westkämper Jul 13 '10 at 07:23
  • Since I've faced compliance issues with both, my reference is the spec, I learned that I can't use EclipseLink as "reference". – Pascal Thivent Jul 13 '10 at 07:27
  • Fair enough, my compliance experience is restricted to the JPQL part. I have used the full grammar of both for Querydsl translation and had more compliance issues with Hibernate. – Timo Westkämper Jul 13 '10 at 07:51
  • 1
    Well, the reason for my question is that I believe to have a comliance issue, too. Pascal already tried to help, but it didn't work (see http://stackoverflow.com/questions/3225103/hiberate-jpa-nullable-values-objects). Briefly, I am trying to make use of nullable attributes, and Hibernate/MySQL don't behave like expected. I've tried the same with EclipseLink (identical code) and it works. However, you say that EclipeLink has it's own issues. That is really, really sad. Would it be appropiate to say: It is better NOT to make use of JPA2 at all and use pure Hibernate syntax instead? – Ta Sas Jul 13 '10 at 08:54
  • 1
    @erlord, if this a Hibernate bug, then file it as an issue in the Hibernate JIRA. I'd still continue using JPA annotations and annotation based configuration. – Timo Westkämper Jul 13 '10 at 09:27
  • 1
    @Timo I agree that Hibernate has some "glitches" with JPQL @erlord I've faced bugs with all the major JPA implementations and believe things will get better with time and I still continue to use JPA. In your particular case, I would suggest to use a `Float` anyway to be able to set it to `null` at the object level. But there is indeed a bug and you should report it. – Pascal Thivent Jul 13 '10 at 10:58
  • 1
    @all: please, consider my self-answer of previously mentioned issue at http://stackoverflow.com/questions/3225103/hiberate-jpa-nullable-values-objects ... that was not a Hibernate bug, but a bug of my capabilities ;-) Hence, I will carry on with Hibernate, just because of the bigger community, and with JPA2, because it is standard – Ta Sas Jul 16 '10 at 09:33
26

IMHO It is always better to use a standard api where possible. Your own example shows this perfectly. You were able to try your identical code on two providers when one failed to work as expected. Switching to any native API prevents you from doing this.

If using EclipseLink as your JPA 2.0 provider works well for you, then use it. If you do happen to run into an issue, file an EclipseLink bug, and get help on this forum, or the EclipseLink forums and Newsgroups.

ROMANIA_engineer
  • 54,432
  • 29
  • 203
  • 199
Peter Krogh
  • 362
  • 2
  • 2
9

From my experience, with Java Perf Profiling. My apps built using Eclipselink seem to perform a lot better than with Hibernate both in Data insertion and retrieval. Hibernate however is more widely used and provides a bigger forum for support.

In production, I will simply take Hibernate for this reason.

Tunde Pizzle
  • 787
  • 1
  • 9
  • 18
2

Just pick and stick with one. Standards are just in the end guidelines and every implementer can implement or fail to implement the standards accordingly.

e.g.

  • EclipseLink has issues using something basic such as JPA @Converters though supposedly recently fixed through IBM http://www-01.ibm.com/support/docview.wss?uid=swg1PI73277

  • Hibernate's JPQL implementation does not understand boolean values that stand on their own more specifically I had to change my JPQL to say

    from Participant p where not p.cancelled

    to

    from Participant p where p.cancelled = false

The other thing is you're building things in Spring and you're likely going to do the improper but common approach of changing the class loader to PARENT_LAST order so your classes are used rather than the application servers.

If you plan to do the proper way and use the JPA that comes with the application server just be a bit wary in that your Application Server implementation may be buggy.

Transaction wise your application, specifically Spring must handle things for you.

Archimedes Trajano
  • 35,625
  • 19
  • 175
  • 265