views:

735

answers:

2

I'm researching the development of Enterprise Applications in Java, .NET and Groovy. For each platform, we're going to try how hard it is to realize a simple SOAP web service. We'll use the tools and libraries that are most commonly used, to research the real world as accurately as possible.

In this regard, would it be best to use the new JPA (Java Persistence API) for persistence, or plain old Hibernate with it's custom API that existed before JPA came around?

+8  A: 

As you're probably already aware, as of 3.2 Hibernate is JPA certified. You can easily use Hibernate as your JPA provider without having to use any of Hibernate's "custom" APIs.

I'd recommend using straight JPA with Hibernate as the provider. And use annotations rather than XML (much nicer).

Then when you need a little something extra you can always get the Hibernate Session. For example I often find I need to do this in order to pass a collection to a query as a parameter (setParameterList).

Damo
I know, but in a recent lecture we attended it was expressed that JPA is still immature and doesn't expose all the advanced features yet.
Bart van Heukelom
Keep in mind that JPA also has to act as a lowest common denominator between the underlying persistence layers it supports. So if Hibernate has whizzbang feature A and Toplink doesn't, then the JPA API can not expose the feature.
James McMahon
A: 

It's funny how you worded your question

new JPA ... or plain old Hibernate

Sounds like one has been around forever and the other has just been released. Of course it's not true. JPA was influenced not just by Hibernate but also by TopLink and by J2EE entity beans. The first reference to JSR 220 draft is back from 2003 - how is that for new? If you use JPA with Hibernate you still use Hibernate and is free to apply any proprietary extensions Hibernate has.

So the choice is yours: use proprietary API or use equivalent established and standard API...

grigory